Sunday, July 10, 2011

Software Estimation - Fibonacci Meets PERT

In my previous post I described an organic process by which I solicited feedback from team members.  The feedback was a Fibonacci sequence number that was used to roughly estimate the complexity and/or work effort on a JIRA task.  This approach is only effective when you have a good team that you can rely on and trust to do the right thing.  This number is just an abstract level indicator of the effort that our development team estimates/recommends for a particular task.

Alone, the Fibonacci number is useless to the business users or project managers.  This is our number.  It carries with it our insights, based on our knowledge, and our experience.  To be useful to others, we must convert it to some metric that they can use.  Enter PERT.

If you are looking for an exhaustive instruction on estimating with PERT, look elsewhere.  I use the typical PERT formulas with a few tweaks here and there.  In the past I have used several multipliers:  Developer Skill Level, Conflicts, New Technology, Code Re-use, etc.  I now have found that the team discussion with Fibonacci output eliminates the need for most of these discrete multipliers.  If you don't trust your team's number, you can always change it.  However, be prepared to communicate to the team as to why you usurped their authority.

For conflicts, I use the industry standard of 0.7. That is to say that we only get 70% of our day to develop.  The rest is consumed with production support, administrative duties and other tasks that conflict with our development efforts. Most of the time, developers discount this or ignore it all together.  I use 1.3 as a multiplier to calculate the expanded time due to a 0.3 reduction in productivity.

An example spreadsheet is seen below.  Obviously as we approach the higher Fibonacci numbers the estimates approach a point at which they are no longer realistic.  This is not a one-size-fits-all approach.  In fact, this method requires tuning over time to better fit your teams velocity and accuracy.

There are multiple levers that can be used to adjust the PERT output of column "E".  This is part of the tuning process.

The main idea is that you remove the complexity of the feature estimates from your development team, when you are still forced to estimate and execute your project in a  waterfall fashion with reasonable predictability and reproducibility.

No comments:

Post a Comment