Struggling scrum teams often have carry-over from previous sprints. These are items that were planned for a previous sprint, but when that sprint ended, the work was not done.
Signs of struggle include unhappy and confused stakeholders, delivery running behind schedule, and demoralised team members.
When the scrum master or someone else on the team is asked “What about these items that were not done?”, responses include “Yes we don’t always finish the sprint”, or “That’s ok, we’ll just do it next sprint”.
It is essential to finish everything that was committed in a sprint, and any time it does not happen some reflection and revision must take place. If it happens regularly, there are systemic issues that must be identified and addressed.
But why is it essential?
First, the sprint planning sessions are commitments to stakeholders. By regularly making and meeting commitments sprint after sprint, the delivery team builds credibility and trust. In contrast, missing these commitments will leave stakeholders questioning the competence of the team to plan and deliver, and in turn, the value of the team.
Second, and perhaps most obviously, not completing sprints will delay the delivery schedule. The impact could include milestones, planned launch dates, and budgets.
Third, imagine how it must feel to be on the team that regularly misses its commitments. They spend hours refining and planning and after a few incomplete sprints the planning starts to feel meaningless. “Will the goal be met? Who knows? Does it matter?” I know that would negatively affect my enthusiasm for the work at hand.
How do we make sure we finish our sprints
The first place to look is the sprint planning sessions. Make sure any user stories being considered for the sprint meet the Definition of Ready.
Next, is everyone buying in to the sprint plan? At the end of the sprint planning session we go one-by-one through the team and make sure everyone feels confident the scope will be completed. If there are hesitations, we address it. That might include breaking things down further or replacing some scope with something else that everyone does feel confident about.
Another important place to look is resource allocation. For everyone responsible for getting the work across the line, will they be around to do it as expected? Is there variance due to other commitments? Product owners conducting user acceptance testing are especially prone to this because they usually have other activities outside the delivery team taking their attention. Steady resource allocation makes it much easier for the team to make commitments they can meet.
What about ‘stretch’ commitments?
Stretch goals are good way to improve performance, exceed expectations and even reinvigorate the team. In a sprint plan, this would most likely be an extra one or two user stories above and beyond the expected velocity of the team. For example if the team usually delivers 20 story points per sprint, they can add an extra three story points as a stretch goal.
The key is to make these stretch goal items clear from the outset, during the sprint plan but before the sprint starts. You can add “*stretch goal*” in the story title or as a label in Jira. When the goal is met, everyone can see where the team has gone above and beyond. If the stretch goal is not all met, everyone can see it was always meant to be something extra. Importantly, it is also clear the team is not dismissing part of a missed commitment as “oh that was just a stretch goal”. Make it clear from the ouset what is and isn’t part of a stretch goal.
