How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps by Martin Fowler

Referred URL - http://herdingcats.typepad.com/my_weblog/2014/04/how-to-fix-martin-fowlers-estimating-problem-in-3-erasy-steps-1.html

Martin Fowler has a nice post about estimating software development projects in an agile paradigm.
It starts like this

• What confidence level are you needing for the estimate you're asking us to do?
• What confidence level have you assign to those estimates you handed me?
• What is the shape of the Probability Distribution for those estimates you want me to use?
• No answers to these questions from the High School Statistics class? These are pure guesses and we're going to be late and over budget before we start.

• Look to similar past performance work to see if we can extract classes of work that can be used as the basis of estimating the new work.
• Don't have any past performance, ask if this project is inventing new physics, because that's the only reason it hasn't been done before. Go ask someone, go on the web forums and search around, go down to the cafeteria and ask, go across the street to Star Bucks and ask. 
• Better yet, go cobble together a walking skeleton to see if we can build our own reference class.
• DO NOT GUESS, use agile to find out before we proceed.
• Assign a confidence interval to all the estimates so we can determine where the problem children are and record that confidence for later.
• Establish agreement - this is an agile team and full and open communication with the customer and management is part of any functioning agile team - on the credibility of the estimates and their proper use.
• The Straw man of management misuse in an agile paradigm is just that a straw man, don't let it happen, stop whining, stop being Dilbert. Insist on behaving in the agreed manner as members of the agile team, otherwise we are just AINO (Agile in Name Only).

• When those statistically acceptable set of estimates are arrived at, make them part of the release plan. And make sure their confidence intervals are publicly visible and can't be ignored - the BIG VISIBLE CHART is one way.
• Color coding can work. Standard Deviations from the Mean can work. Anything can work as long as it is recorded in the plan, agreed to by the team - remember those agreement processes we did when we formed the agile team.
• Revisit those confidence intervals and the Most Likely † value for the estimate every time we release something, start to work on the next release, or do anything that impacts our confidence in the estimates. 

• Actuals HAVE to be different than the estimate. That's why it's call an ESTIMATE
• Go back to the High School Statistics book and reread the definition of an estimate. Don't let anyone tell us estimating is guessing. If they do, they didn';t take that High School Stats class

An estimate is an indication of the value of an unknown quantity based on observed data or a model of the possible values that would be observed.

• Adjust those estimates for actual work. Adjust them for anything and everything that impacts the work.