7 reasons why software estimates don't work
First letâs start of by defining estimates. Estimates can mean a lot of things. In the widest sense, as a synonyme for forecasting or guessing about the (near) future or at all thinking and imagining whatâs ahead, it refers to a practise we indulge in all the time, probably hundreds of times a day. We estimate when we have to leave home in order to make it to work in time. We estimate when we have to start a task in order to get done by a deadline. We estimate in a matter of seconds whether a task is large or small. This is not what Iâm talking about here.
Estimates in this context are expert estimates of software development effort. Itâs the detailed breaking down of tasks in order to reveal complexity and limit uncertainty. Oftentimes estimates are made by an entire group of experts, an entire team. In Scrum methodology this is considered important in order to include more perspectives on the task at hand, to reach consensus and to have the whole team on board.
Ok, now weâve got the definition in place. So whatâs wrong with this practise of expert estimation? I argue there are (at least) 7 things:
1.Â
Estimates cost
The hours it takes to gather a whole Scrum team, dig deep into the tasks, uncover hidden complexity, check with subject matter experts/product owners and do at least a minimum amount of documentation - it amounts to a great deal of hours. In a team I was working with, i found they spent 80 hours estimating during a period of 3 months. Thatâs two weeks worth of potentially valuable time. And itâs a lot of money to spend on a practise that neither yields value nor is in any way accurate in predicting actual software development effort.
2.Â
Estimates have short shelf life
In the worst of cases, teams makes estimates months ahead of the time they are actually going to put in the effort they are estimating. And in order to make âgoodâ estimates, developers need to dig into the subject matter, uncover dependencies, unveil complexity. And make assumptions about solutions. A lot of good thinking and good conversations goes into the process. And, as the Agile Manifesto teaches us (because we are of course good, agile practitioners), we value runnings software over comprehensive documentation. So we try to keep the documentation of these good conversations as light as possible.
And the, weeks or even months later, we pick up the tasks again - and we have (almost) no clue as to what we were thinking back then. All the valuable insights are lost to us.
3.Â
Estimates become irrelevant
Cause who havenât experiences that half their initial backlog has been deemed irrelevant by the time you get halfway into the project. So all that time estimating is indeed worthless
4.Â
Estimates inhibit creativity
Since you have to make choices about solution, those choices seem to stick with us whether we like it or not. This limits what creativity we get to use during the project, either because the choices we made actually the solutions we are committed to or because they are the solution we have imagined and we are anchored to them.
5.
Estimates are counter productive
âWhat gets measured, gets doneâ
...and we start doing what the estimates say against our better judgement, against what we learn as the project moves forward.
6.
We are unable to estimate
There are numerous papers and research on how lousy we are at estimating software effort. There are a number of cognitive biases that contribute to this, the most prominent being optimism bias, anchoring and confirmation bias.
7.
Estimating are killing motivation
No comment needed, right?
 So where does this leave us? How then do we plan, budget and control our software projects? The next blog post will provide the Answer.
Stay tuned!
















