My Twitter stream flooded with estimation related topics yesterday. We’re currently starting up a new project, so the timing was perfect and the topic highly relevant. Here are some recommended blog posts from yesterday on the topic:
Estimation is at the root of most software project failures
In this blog post Rob Bowley explains why we’ll never be very good at estimation, especially the long range high level estimates – mostly for reasons outside of our control. Still many people in the Agile community talks about estimation as if it’s a problem we can solve. The discussion after the post is also highly recommended:
http://blog.robbowley.net/2011/09/21/estimation-is-at-the-root-of-most-software-project-failures/
You Mean I Can’t Even Estimate? The Planning Fallacy in Action
A post by Jim Benson, down the same alley as Rob Bowley. Explains how we might deal with the fact that there will be a variation in every activity, and that we tend to underestimate a given task even if we’ve done that task many times before:
http://ourfounder.typepad.com/leblog/2011/09/you-mean-i-cant-even-estimate-the-planning-fallacy-in-action.html
Estimate the total cost of Agile projects
Kane Mar first describes why estimating the cost of software is, at best, an educated guess. Then he explains how to deal with this when estimating the total cost of Agile projects:
http://www.scrumology.com/2011/agility/estimate-the-total-cost-of-agile-projects/
Story estimation on Agile teams
A comprehensive Q&A by Praful Todkar. Who should be involved in estimation? Should we time-box estimation? Is pre-analysis necessary before estimating a task? What should we include in our estimates?
http://computellect.com/2011/09/12/story-estimation-on-agile-teams/
On the previous project we started off estimating stories before taking them into the sprint. When we gradually moved into the maintenance phase, we discovered that we only selected stories by priority – not size. Also, the stories were quite small, so estimating them seemed like a major overhead.
Not giving any real value anymore, we decided to stop estimating stories. Later, when we applied Kanban, we removed the iterations as well. We’ve managed well without estimation for about eight months now, instead focusing on the flow and maximizing throughput.
So here we are, about to start a new project. I think the time is right for us to reflect on why we estimate stories, and why we (try to) estimate the total size of the project. After all, for this particular customer, Scrum is the “company standard” – they’re used to estimating stories before prioritizing and starting them. Therefore, I think this is where we will start, this is what the company knows. But who knows where we will end up?
Do we still need estimates, or do we eventually get into trouble anyway when using them? Do you know other relevant blog posts on this topic?
Disclaimer: This blogpost was originally published on a different platform. Formatting may be incorrect, links may be out of date.
Jørn Hunskaar 