INFORMATION NOW

There has been a lot of noise recently about eliminating estimating for software development projects. Id like to thank Terry Bunio for putting out his thoughts as a rebuttal here. (Note - Terry sits right beside me so weve 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:


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 well 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

I read an interesting list of agile practices at Naresh Jains blog: Explosion of Agile Practices.  I think there is a lot of overlap in his list, but it made me re-visit what I think the core list of lean and agile practices should be.  My list is below in no particular order.  Each item can be expanded - for example, Technical Excellence implies TDD, simple design, following SOLID principles, etc.

1. Daily Stand-ups
2. Visual Project Management
3. Customer Accessibility
4. Technical Excellence
5. Frequent Delivery
6. Frequent Retrospectives
7. Continuous Improvement
8. Continuous Integration
9. Co-located teams
10. Iteration Planning
11. Team Estimating
12. Acceptance Tests (and automation of those tests)
13. User Stories
14. Self Organized Teams
16. Iteration Demos

Update 8/15/2010:
- And one more... Deliver Value!