Two sprint planning mistakes that wreak havoc in software development teams
In an ideal world, your development team gets all their planned work done in a sprint without too much stress or chaos. In the real world, however, things don’t always go that smoothly. Sometimes, the decision has to be made whether the unfinished work will flow over to the next sprint, or whether the team does a few late nights near the end of the sprint to get it done.
Why does this happen? It is largely due to two common mistakes Scrum teams use in their sprint planning meetings: asking for single-number task estimates and planning work to fill 100% of the development team’s estimated capacity.
Mistake #1: Single-number task estimates
Often, development teams try to have very tight, very accurate estimates for each task. In these cases, team members won’t leave much buffer or wiggle room in their estimates. When a developer is asked, “How long is that task going to take?” their answer is usually based on the best-case scenario. When the developer’s best-case scenario doesn’t happen because they get interrupted, they have too much work-in-progress, or the handover is delayed – in other words, because they’re operating in the real world – the task duration blows out and rolls over into the next sprint.
Mistake #2: Planning to fill 100% estimated capacity
When teams plan how much work can be done in a sprint, they generally base the plan on the capacity of everybody in the team. For example, if a team has five developers and works eight hours a day, that’s an estimated 40 hours of capacity from each in a five-day working week. So, for a two-week sprint, a team of five developers will estimate roughly 80 hours of development from each developer, give or take a few hours. Unfortunately, this way of estimating capacity doesn’t account for variation occurring.
For example, imagine a developer is waiting for a task to come from another person. If the handover is chewing up the developer’s estimated capacity, then they might choose to chase up the person they’re waiting on. On the other hand, they might also drag on the task they’re doing, or perhaps pick something else up off the ‘to-do’ pile and start on that.
If developers can only pick up new work from within what’s been planned for the sprint, that’s not so bad. It’s probably not going to increase work-in-progress or multitasking too severely. On the other hand, if a developer can pull work from outside of the sprint, that’s when the work-in-progress starts to blow out a bit more. In other words, their capacity is being used in ways that might not have been planned into estimates. Even if it was planned for, people still have to guess at how long they are going to have to wait. Neither possibility is very attractive.
Is there a better way?
The short answer is yes. In fact, there are two ways to improve the reliability of task estimates and completion of work planned for each sprint.
Estimating a range or bracket
Rather than estimating to a single exact number, estimating with a bracket allows some variability to be absorbed. For example, if a developer thinks a task is going to take four hours and they know that the duration of the task can actually double if things don’t go smoothly, they might say the task will take, “Four to eight hours.” That task is given an estimate of six hours, which includes a little bit of a buffer to allow for variation.
Placing a buffer at the end of the sprint
The other way to protect estimates from variation is to use a buffer, but to put that buffer at the end of the sprint instead of at the end of each task.
If the buffer is placed at the end of the sprint then while the sprint length is still two-weeks, for example, only one and half weeks’ worth of work is planned into the sprint. The remaining half of a week is used to buffer variation in case any estimates were wrong, or delays occurred. If there is spare capacity at the end of the sprint because the buffer isn’t fully used, then the development team can always use that for bug fixes or planning the next sprint in advance.
Smoother sprint execution
Whether you choose to add the buffer into each task estimate or at the end of the sprint, this will help smooth the execution of the sprint and make task estimates, and as a result, delivery of planned work, more reliable for your development team.