Scrum and other agile processes advocate using time-boxed periods called a sprint or iteration in order to focus a team on getting work done. The idea is that the team will select an amount of work about this size of their capacity and commit to completing that work during the sprint. How the team decides what their capacity is and what work to commit to is for another blog. What we are concerned with right now is what to do with work that isn’t completed at the end of the sprint.
There are a couple of approaches to solving this problem. Keep in mind that the goal of the team’s commitment is to get that work done in the sprint. The team should work on finding a capacity that allows them to get their commitments done. That said, it is expected that sometimes there will be an issue that will prevent work from getting completed in the current sprint. That happening sometimes isn’t a big deal and shouldn’t require the team to change its practices and process. If on the other hand, the team seldom or never completes their commitments, they should take a look and change what they are doing. One of the benefits we get out of sprints is the ability to become predictable. Predictability is one of the best drivers of trust between the technologists on the team and the business people on the team. Moreover, trust is what helps the Product Owner (PO) and Scrum Master (SM) push back on demands of the stakeholders. Predictability, as in work gets completed at the rate and pace the business can rely on is what forms the basis of expectations management in Agile. It allows the business to plan within an Agile context.
This leads us to the question of what to do with work not completed at the end of the sprint. What should you do? Ideally, the work goes back into the backlog for the PO reprioritize. The PO will decide when the work might be ready to be a sprint candidate again. If the work leaves the software in a non-production state, you might have to clean up your code base and tests to remove the incomplete work. This ends up being fairly inconvenient so a lot of the time the story just rolls into the next sprint. This rolling into the next sprint is so common most people aren’t aware that the PO could pick something else.
One of the questions I get asked by new teams is, “What do we do with the points?”, meaning “How do we get credit for the work we did?”. This is determined by tracking the team’s velocity, which is the running average of the work the team can get done in a sprint. The only reason we track velocity is to help the team determine a capacity for the next sprint, i.e. figure out how much we can fit into the sprint or iteration. To me, the whole question of how do we get credit for work we didn’t complete is wrong-headed. Velocity should reflect the work the team got done and nothing else. This leads me to what I recommend teams do with incomplete work:
- Move the story to the next sprint
- Resize the story for the work left to be done
- The team only puts points into their velocity for work they got to done
This means that the points from the sprint where the team worked on a story but didn’t complete it are never factored into velocity. As some people have put it, “we just lose those points”. This might seem harsh to some people but there are some good reasons for it.
- The team should only count what they got done since their capacity is what stories the team completed.
- You want to encourage the team to break work down into smaller, better-defined stories. This helps reduce the risk of not completing a story within the sprint.
- If the team is inflating what they can get done by adding points for stories they didn’t complete, it will be harder to find a story capacity equilibrium and get to a predictable velocity.
I see teams that don’t use this method overcommit all of the time and struggle with becoming predictable and credible in the eyes of their business. Even when the business is asking you to overcommit they will hold missing the commitment against the team. It is far better to commit to an amount of work you can get done at a sustainable pace than to overcommitting. Your business will end up respecting you for making your commitments and by becoming predictable.
The curious case of incomplete work usually first comes up in Scrum during sprint 3 or 4 when the team is writing and committing to stories that are too big. They haven’t yet learned the value of small stories. For instance, one of the team I have worked with had a velocity of 20 going into the 4th sprint. They had two 13 point stories listed as their top priority. I agree that these were the top priorities at the time. I asked them if they could break the stories down more and make it so that they could commit to something more in line with their velocity so far. The team felt really confident and decide they wanted to try to get the two 13 point stories done in a sprint and so they committed to them. As it turned out there was some extra complication in one of the stories and the other story spent some time during the sprint being blocked by something outside the teams control. By the end of the sprint, the team didn’t get either story done. They certainly did work, good work at that. They just didn’t break their stories down well enough. During the retrospective, we talked about not getting any stories completed and resulting in a velocity of 0. We talked about ways to mitigate this problem in the future, including breaking stories down more. This team learned their lesson and didn’t have another story what was more than 25% of their capacity in the future (i.e. any story larger than 5 points was broken down more).
Other patterns I have seen teams use for incomplete work, but discourage, include:
- Rolling the work to the next sprint and applying all of the original points in the sprint the team completes the work. This inflates what the team can get to done and could set up unrealistic expectations going forward. It can also lead to the team working at a pace that isn’t sustainable in the long run.
- Spitting the story into two stories, one with the work that was completed in the current sprint and one that will roll forward into the next sprint. This is a lot of overhead that doesn’t add value to the process. It also means the team is delivering work at the end of the sprint that isn’t production ready.
In the end, I don’t like these patterns because they don’t encourage the team to think in smaller units like smaller stories, smaller tasks, and smaller releases. Smaller allows the team to get more feedback and increase their ability to react to change and feedback. It allows them to learn more and to evolve the project more over time. Smaller also helps reduce many kinds of risks, such as the risk of not getting your sprint commitment done, the risks associated with changing a codebase, and the risk of introducing hard to find bugs.
