Self-Fulfilling Estimates
How to hit your dates with less headache
Today we’re going to be talking about estimates. My focus will be on time estimates (“when is this going to be done?”) but much of the advice can apply to budget or space estimates in some situations. You know your situation better than I do, so I’ll let you make that call.
We’re also going to be talking about fallacies today. Yes, coming up with estimates is often a fallacy in the first place! But this isn’t a #noEstimates article. You’re going to eventually find yourself faced with the question, and “when it’s done” won’t be a good enough answer. Today we’re going to talk about the mental traps that humans continually fall into when doing estimation so you can have a fighting chance of avoiding them.
The Situation
For most of my career, I was a team lead for small software engineering teams. Most companies were running the Nailed It! version of Scrum. We had our standups, sprints, retrospectives, and bi-weekly planning. But we still had long term estimates to give the business predictability around release dates. These companies of course would measure each team’s capacity and how often they hit their sprint goals. Those numbers go into the spreadsheet and management suddenly knows if we are going to hit our dates.
If you’ve been in software for even a few years, this is probably a familiar story — as is the inevitable follow-up. Some team misses the mark on the sprint work. Maybe someone got sick. Maybe someone quit. Maybe the work turned out to be more complicated than we expected. Maybe that critical bug showed up at just the wrong time. It doesn’t much matter why the schedule got screwed up, just that the team didn’t account for it in their estimates. Management comes down and demands better estimates, and soon the team is spending four hours a week staring at Jira and hating the world.
Around that time, the leads of other teams start asking me questions. My team is consistently around 90% accuracy on our sprint goals, while my peers struggled to achieve 60–80% accuracy, even with the long hours of planning. At first, they thought it was a process problem. If only they were better adherents to the Scrum guidelines, they’d see better results! When that didn’t work, they…
