Home > Point2 - Technical > The Concept of Feature Fidelity

The Concept of Feature Fidelity

February 25, 2010

When we’re building software, we often have a desire to deliver something that will blow people away.  It makes sense right?  Why would we want to deliver something that isn’t impressive, doesn’t work all that well, doesn’t look really pretty etc.

Well, it just so happens that there’s a good reason you’d want to do that, because it still delivers value, even in it’s often simple and unrefined form. 

Consider this scenario, a client comes to you and asks you to build them a chair for their office.  They want it to roll around, comfortable, adjustable height, nice arm rests etc, and they want it as quickly as possible because they don’t have a chair at all now.

Using the typical mentality of not delivering anything until you think it will blow people away, you go away and over the course of a month you build a fabulous office chair.  You showed some pictures of it along the way to the client and they were pleased with the design, however they really wished they could have been sitting down at their desk while they looked at your designs…

The concept of fidelity is simply to deliver the simplest thing that provides value as soon as possible, and the move on to refine it.  Using the chair example, the client wants a fancy chair, but the client also currently has NO chair, so obviously just having anything to sit on provides SOME value.  Thinking in this way, the lowest fidelity solution that will deliver some value to the client might look something like this:

milk crate

The client will obviously not be satisfied with a milk crate as the final product but it isn’t the final product, it’s the first iteration of the final solution.  You would tell the client something along the lines of “here’s what we came up with in the first day, turn this upside down and it will allow you to sit at your desk, we’ll be back in a few days with an improved version for you.  A couple days later you return with:

chairYou tell the client that it’s a little more comfortable than the last delivery, and looks better as well.  You will further refine the chair and be back in another week.  After a week you come back in with:

swivel chair The client takes a look at what you’ve delivered, sits in it, the padded chair is comfortable, it looks stylish, and they tell you this is my chair, this is what i want, don’t make any more changes.

So, what are the main differences here?  The client ended up with an end product they were happy with in both cases right?  The second method had a couple key benefits though.  First of all, the client had results in hand and was able to use them (start sitting down) the next day, instead of having to wait for a month.  Also because the team was delivering improvements regularly the client had many opportunities to suggest how they would like things changed.  Finally, the client has the opportunity to stop the development of the product early for any reason and still be left with a usable product!  So whether it turns out that the client is happy with less than they originally asked like in my example, or if the client just ran out of money and had to stop early, they are always left with something usable.

You could make the argument that this is just iterative development, and technically you are correct, however it’s important to remember the fidelity aspect which is that each iteration should provide a usable product that provides value.  Consider another way to iteratively deliver a chair to the customer.  In the first iteration you deliver fully refined wheels, in the second you deliver the adjustable chair post, in the third you deliver nice leather wrapped arm wrests, in the fourth a nice padded leather seat, in the fifth a nice leather chair back, and in the sixth you put it all together.  That’s iterative right?  You produced and delivered a piece of the product in each iteration and showed it to the client.  The problem is that you weren’t delivering any value with each iteration.  The customer doesn’t realize any value until the last iteration when you put it all together, which means if the project had to be stopped early, the client is left with nothing useful.  Even worse, the customer can’t see how everything is going to work together until you put it all together for them, so they don’t have much ability to give feedback on your work.

Always deliver in iterations that provide value to the client, so they are left with something useful that provides value no matter how deep in to the project you are.

by: Chris Dagenais

%d bloggers like this: