Software estimation is difficult. Programmers tend to be short-term pessimists and long-term optimists; this skews estimates in many directions. Product owners often struggle to describe what they want in a way that a developer can accurately estimate. And, at the end of the day, we as humans tend to forget the bad and remember the past with a certain nostalgia, hurting our ability to estimate accurately. Here are some patterns we’ve noticed in our work that cause estimates to be inaccurate.
Not using relative sizing/story points
Asking your developers to estimate how many hours a task is going to take is a slippery slope. First, we, as developers, often struggle with giving correct time. Second, think about the spicy food-truck conundrum, the problem that happens when “developer 1” ate too much spicy food-truck food and couldn’t come to work due to “intestinal discomfort.” All the sudden, you are left with “developer 2” and “developer 2” might take twice or half as long as “developer 1” for any number of reasons. While being off on a task or two won’t kill a project, when 10 of those tasks pileup, your project will slip.
Instead, agile practitioners favor the use of story point estimation. This technique groups product backlog items (PBI) together that should take a similar amount of time. If you rank two PBIs a 5 they should be relatively equal in effort. Once you have your relative size assigned, you use “yesterday’s weather” to decide how many story points your team can do in an iteration.
Getting estimates too detailed too early
If you’ve been in the project management business or software development business more than a minute or two, you’ve come across the Gantt Chart from Hell (GCFH). It usually requires 4 monitors to display, has hundreds of rows on it with arrows pointing all over the place, and is truly your project manager’s baby. You know, the ugly one that on one wants to admit is ugly.
Issues with the GCFH is a topic in itself. For now, I’ll highlight a key problem with the GCFH: if you feel you can plan your project at a high level of detail for any time beyond the next 24 hours, you are a better fortune-teller than most. Software development is far too complex and unpredictable to be accurately planned to the hour or even day or even week.
Instead, use concepts such as “yesterday’s weather” and relative estimation to estimate your projects on a sliding scale. You can create product roadmaps that have a year or two on the forecast, but adjust the detail appropriately. You need to be agile and adapt to change; so make sure your long-term planning is flexible and reflects uncertainty.
Not involving enough people in your estimates
A common failing of new project managers is to rely on a few key people to generate estimates. Effective estimation is a whole-team effort. Your testers and analysts have just as much to say about the complexity of something as your developers do. Good agile estimation requires good team communication and discussion.
Failing to inspect and adapt
As an agile team you should constantly be inspecting your results and adapting your estimation based on validated learning. Every few iterations you should take time to check your estimation process. Determine if something that you once assigned 5 story points to is still a 5. Don’t change what you did in the past, instead, apply that learning into what you are doing today and make sure it’s reflected in your next estimation session.
Not taking the time to get your team on the same page
Taking the average of everyone’s estimate is a pattern I’ve often seen and done in estimation meetings. While this could be a way of coming to consensus, it should never be a tool to avoid conflict. The absolute most important tool in exact estimation is team conversation. Instead of jumping to an average, have your team discuss the reasons for different estimates. Encourage healthy conflict and strive for true consensus. If you can’t reach it, then be introspective and find out why. If you avoid conflict you might never find out what is hurting your estimates and you won’t have the opportunity to improve.
