Have you ever had the experience of being in a team that consistently overruns on its estimates and found that, over time, this becomes demoralising? Have you also found that once it becomes common practice for estimates to overrun and for sprint goals never to be met, this leads to a downward spiral of team disengagement and demotivation? It might even start to feel like these problems are unsolvable and just "the way things are" in software development. If you've had these experiences, then this is the blog post for you.
The good news is that many teams in the industry have solved these problems and put the solutions into practice successfully. This is the first part of a two-part series on estimating in software, which is all about why estimates matter. In the second part, we'll examine why estimates often come up short and how we can make them great.
The case for good estimates
Why is there a need to write a blog on the value of good estimates in the first place? Good estimates seem like a reasonable thing to value. Isn't this a given? People can have different intuitions on them, and some, particularly at the project level, can feel inconsequential. The thinking goes, "They're just a best guess; if the stories overrun, they overrun. We're 'agile' anyway, so what does it matter?". But I would say this is almost never the experience of the developer. For a developer, overrunning an estimate is almost always unpleasant, which is why many developers get frustrated.
Anyone who's tried to estimate anything knows that it's hard and involves effort and skill to get it right, and I think that explains why they're so often way off. We rarely take the time we need to do them properly. However, before we commit to undertaking that effort, I think it helps to remind ourselves why good estimates are worthwhile.
There's an obvious benefit to the business from good estimates. After all, it gives a more realistic picture of how long a major piece of work might take and how big the backlog is. This helps with further planning and prioritisation, not to mention managing the expectations of users and stakeholders. In this article, though, I would like to consider this from another equally important perspective - developer wellbeing.
Good estimates mean more productive developers
I want to make the case that good estimates matter because they enable developers to regularly complete their stories within the estimated time, making for a better developer experience. How does this happen? Well, hitting targets is rewarding and provides a sense of achievement. The anticipation of that reward is highly motivating. Conversely, the fear of not meeting the estimate can create anxiety because the developer is made to feel they're not going quick enough or incapable of doing it in the allocated time. This experience can be illustrated with the following two charts.
The story is well estimated in the first scenario, and the developer completes it on time. In this case, motivation and anxiety stay pretty constant the whole way through. In the second scenario, the story is poorly estimated. As often happens, there's a point of realisation midway through completing the story when complexities emerge, and the dev realises they won't get the story done on time. It's at this point that motivation starts to drop, and anxiety rises. The decrease in motivation and increased anxiety negatively affect productively, thereby compounding the problem, and so the story gets finished much later than estimated. In addition, corners may get cut, reducing quality. The dev eventually finishes the story, but the feeling afterwards can be a failure rather than a success. Rather than picking up the next story on a high and building momentum, they feel dejected and demotivated. This can cycle from story to story, leading to a demoralised and underperforming team.
The antidote to this is stories that are well-estimated. It also gives a more realistic picture of the team's workload, enabling better planning and prioritisation, and keeps developer wellbeing high and happy devs are productive devs.
Conclusion
It might be tempting to wonder why we don't just assign extremely generous estimates to all our stories so that devs consistently come in under-estimate with a guaranteed feel-good feeling. Aside from making the estimates unhelpful from a business point of view, this question can be answered by Parkinson's law, which states that the work will expand to fill the time allocated. So we want to find a balance with our estimates to apply some pressure while still being realistic.
Now that we've made the case for why estimates matter, the next part looks at how we might come up with good estimates in the first place.
About me: I'm James Propert, a Senior Consultant at SixPivot. I work with teams and organisations to help them create great software.
Comments