Use Fuzzy Hours for Your Software Task Time Estimates

Like many software development shops, we need to provide estimates of the time required to fix each bug and add each new feature.  The primary reason for the estimates is to set expectations for when tasks will be completed and to prioritize what is to be worked on.

As an agile shop, we have tried a few scales for estimating such as:

tiny, small, medium, and large and also the Fibonacci sequence:    1, 2, 3, 5, 8

but the one we have been using for years that we like best is fuzzy hours.

We use the symbols 1,2,3, and 4 where:

• 1 means 0 to 2 hours
• 2 means 1 to 8 hours
• 3 means 4 to 40 hours
• 4 means more than 30 hours

Notice that our ranges overlap and that is what makes them fuzzy.  When an estimator feels an estimate is in a fuzzy zone it is up the estimator to pick one zone or the other based on their gut feeling.

We have also learned that the velocity for all items sized 1 and 2 are the same, and items with a size 3 take only slightly longer to reach a completed state (development, testing, quality assurance, and documentation all complete).  Items with a size of 4 take longer, but only about twice as long on average as a 3.

More reasons that software estimates are inaccurate

One source of inaccurate software development estimates is the residual impact of a new feature. On a recent project we decided that we wanted to persist the user’s column width customizations in the grid of our Silverlight application. We estimated that we could complete this in just two hours, so we did so. However, after we implemented the feature we realized related issues that needed to be addressed and thus all took additional time. Some of these issues were:
• Will the customizations persist if we release a new version of our code?
• What happens when a user resizes the entire form and grid? Is that the behavior we want?
• What happens with a grid designer adds or removes columns from a grid that a user has saved customized column widths for?
• Should we have tied the customizations to the grid id or to the form id the grid was displayed on?

Residual issues and questions like these often show up during the development and testing of a new feature and are not accounted for in the original estimate. Some of these can be resolved in less than ten minutes, but others may take much longer.

What does this mean to a development team? Just that several people should generally be involved in the decision to implement new features and that a few extra minutes should be spent up front to identify as many issues as possible if you desire the implementation time required to be close to what you expected.

Analogy – Estimating Software development is like estimating drive times

Estimating a software development project is a little like estimating driving time.  If you are estimating something you do over and over, like your drive to and from work, then you can provide estimates that are very accurate.  However, there is always a chance for unexpected traffic jams and bad weather that could unexpectedly make your estimate grossly inaccurate.
When estimating a trip that you have not taken before, the accuracy of the estimate decreases with your knowledge of the possible paths and the accuracy also decreases with longer distance.  Is it not the same with software?  Our estimates become less accurate when there are more things we need to do that we are not familiar with, and as the scope of the project increases.