Why good user story estimates matter
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 to never be met that this leads to a downward spiral of team disengagement and demotivation? It might even start to feel like these problems are unsolvable and are 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 that is all about why estimates matter. In the second part we’ll look at why estimates so often come up short and how we can make them great.
Why the 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? Well, people can have different intuitions on them and some, particularly at the project-level, can feel they’re 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 to some degree, which is why I think so many developers get frustrated with them.
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 of why good estimates are worthwhile.
There’s an obvious benefit to the business from good estimates. After all, it gives it 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.
I’d like to make the case that good estimates matter because they enable developers to regularly complete their stories within the estimated time, and this makes 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 are not capable of doing it in the allocated time. This experience can be illustrated with the following two charts.
In the first scenario, the story is well estimated 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’re not going to 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 one of failure rather than success. Rather than picking up the next story on a high and building momentum, they’re feeling dejected and demotivated. This can cycle from story to story and eventually leads to a demoralised and underperforming team.
The antidote to this are stories that are well estimated. As well as giving a more realistic picture of the team’s workload, enabling better planning and prioritisation, it also keeps developer wellbeing high and happy devs are productive devs.
At this point 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 so as 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.