The debate about agile estimating

There has been a lot of noise recently about eliminating estimating for software development projects. I'd like to thank Terry Bunio for putting out his thoughts as a rebuttal here. (Note - Terry sits right beside me so we've had a lot of discussion on this topic recently - especially since we thought someone was wrong on the internet #gasp)

To summarize my understanding of the issue:

• Estimating is a waste because we are going to be wrong anways.
• Estimating is a waste because we could be delivering value instead.

While these two statements have caused a lot of debate, there is a ring of truth in both of them. So, if we are going to do some form of estimating, can it a) help us be more truthful about our estimates and b) increase our ability to deliver value? This is the beauty of relative estimating through planning poker - and here is my main point, bolded and centered for emphasis:

Planning Poker is not just an estimating exercise.

Yes, one of the main outputs of planning poker are points estimates. But it has other results that address the concerns above.

a) It allows us to be more truthful about our estimates:

• Relative estimates in concert with user stories and managing to done enable you to track the velocity of your project so you can predict actuals sooner (i.e. tell the truth about your estimates as soon as possible). In turn, this allows us to make better choices about the future of the project (like helping the marketers decide when to launch a campaign about the project), and measure the results of our continuous improvement experiments.

b) It increases our ability to deliver value:

• Planning Poker is also a scope discovery tool (see my thoughts here). After a planning poker session our team will have a much better understanding of what the client wants and expects - therefore enabling us to deliver it to them sooner and with less misunderstanding and frustration.
• Planning Poker creates team ownership of your estimates - including joint ownership with the client.
• Planning Poker allows your client and users to have a much better understanding of what it takes to build what they are asking for and informs their choices when prioritizing.

In closing, so far all of our clients have required us to create estimates and we'll continue to do that. But, we like to start with points through planning poker because of the value added as above and then take a few stories and extrapolate to hours. After that, we ignore the hours and focus on velocity. This feels like a balanced and professional approach.

**************

Some additional reading on this issue if you choose. The last one contains some ideas that I strongly disagree with and that Terry responded to in the post above (despite his affection for TargetProcess in general).

• http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
• http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html
• http://www.sdtimes.com/link/35401
• http://www.targetprocess.com/blog/2011/04/5-reasons-why-you-should-stop-estimating-user-stories.html