Agile Estimation Theatre

We’ve all experienced what I like to call Agile Estimation Theatre. Imagine it’s the beginning of the sprint and your team is holding a sprint planning meeting. The project manager has built up a set of stories a few of which have subtasks. Now you will spend the next two hours trying to create estimates for each of those stories. 

The project manager starts by reading the first story. Someone asks a question about whether ECS or EC2 are a better solution for the problem which devolves into a 20 minute conversation about the merits of various AWS services. The project manager is forced to stop discussion to leave any possibility of estimating all the stories slated for the sprint. You open your planning poker tab and evaluate your options 1,3,5,7,13,21,34, 55. After a moment you decide on 13 since you are sure the task will take at least a day or two. One of your coworkers then asks whether the numbers are days or hours. That question leads to a 10 minute discussion of what exactly story points are and how they are definitely not a unit of time. The teams votes range from 5 to 34. And then project manager overrides the score to be 21 since that’s what the senior engineer picked.

The two hours continue to drag on. By the blessed end of the meeting your team has ‘estimated’ 4 out of 20 single sentence stories. Since the sprint starts tomorrow the project manager holds a quick meeting with the senior engineer to estimate the rest of the stories before 5pm.

The above tale represents what I like to call agile estimation theatre. We have a sprint planning meeting where we’re supposed to involve the entire team in estimation, so we schedule a two hour meeting and hope for the best. Sometimes it actually works, but often we end up with questionable estimates for single sentence tasks.

The fundamental problem with Agile Estimation Theatre is not investing enough time. To get good estimates you need to have complete stories. You need to break down subtasks and specify them more thoroughly than a single sentence can possibly handle. Then you need to have your team spend time reviewing the stories individually and coming up with estimates. The problem is that it doesn’t make sense to spend several days out of a two week sprint on estimation. To do it right you need to have well specified stories. Building out the stories will take at least a few engineer days. Next you need to have the entire team spend 2 hours each estimating stories individually. Finally you add together the individual estimates and do the sprint planning meeting. Now repeat that process again every two weeks.

The breakdown is that the expected value of the estimates is typically less than the cost of spending a few days to produce good estimates. The organization intuitively knows this which is why we spend two hours in sprint planning instead of two days. But because we want to do scrum or agile ‘properly’ we need estimates. The end results is that we denature the estimates to comply with the process. Launch

I have launched a new website, to focus on software development estimates. My goal is to put longer form and higher quality posts focused on estimates on the new website. I will still be posting here regularly on all things software. 

Software development is a massive multi-billion dollar industry, but our estimation practices are not great. Computer Science degrees focus on math and algorithms without any consideration of estimating projects as a core skill. Most of us in the industry work off of whatever our flavor of Agile practice recommends whether its Scrum, Kanban, SAFE, etc. My goal is to research what we know about estimating software projects, and develop simple ways we can use that in industry. The goal is to do a combination of popularizing better techniques and developing a recommended style of performing estimates. 

Check it out at!