The best part is, this is no secret. From interns to the C-Suite we all know estimation is largely a false comfort. Most of us cope by assuming all estimates are off by some amount and we adjust our expectations accordingly. This is essentially the point of the cone of uncertainty.
Why do so many decisions in our industry hang on this precarious practice? Why, after all these years, have we not either improved estimation or moved on from it? What can we do to make this better for ourselves, our organizations, and our customers? At a guess, momentum, we actually have improved on it, and there are some ways to make it better and more useful.
To understand why we’re always trying to get estimates and basing our decisions on them we really need to step back and understand the role of estimates in the context of a project that is underway. Estimates help the team control work in progress. They also provide a data point for prioritizing work. On an organizational level, they help control risk. There are some people who use them as a measure of capability, but that is an anti-pattern and something that needs to be stopped when it’s found.
To move on from estimating we really need to replace the value estimation gives us. We need to provide a new way for a development team to control their work in progress. We need a new data point to help the product owner evaluate the cost, both time and money, of adding new features or functionality. Without a strong alternative to providing this data, we fall back on estimating. We have gotten better than a project manager trying to guess at person-hours for a feature though.
Through practices such as planning poker, fists of five, and affinity mapping we have gotten better at this game. As a team goes through these estimation practices they get better at understanding the work being asked of them, and over time how much work they can do. This results in the ability to more accurately determine how long new features will take and better control over the work a team has in progress. At its extreme teams may start to look into the concept of NoEstimates, but I’ll leave that for a future post.
If your team is struggling with estimation there are some things you can do today to help make it better. First, get rid of hours and days. Have the team come together and agree on an average task that they get. Once they have it, that task is now a horse, not a 3-day task. Every other task is evaluated not on its own – absolute estimation is the worst kind – but in reference to the one picked. If it’s bigger, is it a bear, an elephant, or a whale? If it’s smaller is it a llama, a dog, or a mouse? Relative estimation is far easier and more accurate and by taking people’s minds off the numbers they can concentrate on the work. When things are bigger than that horse, maybe send them back to the product owner to be broken down. When they’re smaller than the mouse, don’t waste time estimating, just add a couple to the work in progress and call it good.
The other big tip I’ll include today was foreshadowed above. The team. The entire team, not just the senior developer, needs to be part of the estimation process. This is also a great time to include not only the product owner, who is part of the team after all but also a key stakeholder or two so clarity questions brought up by the team can be answered more quickly.
I would be happy to help your team move a step or two forward on their journey of improved estimations. Just reach out to me and schedule a free call to get the ball rolling.
Estimation is hard. When we estimate tasks in the knowledge worker space we’re proven wrong more often than right. This is amplified when we try estimating projects, but still highly applicable when talking about estimating work on an existing project.
