Whenever I coach new scrums or scrum masters, we eventually run into this question: what shall we do with stories that are not finished at the end of the sprint? There’s been a ton written about how to handle this sort of “spillover”, but each new team seems to struggle with the phenomenon. My guidance is always two-fold: what we should do in the short term with specific stories which are not finished, and how we can improve over time to reduce the incidence of this problem.

First Things First

For me the most important principle is this – Done means Done. Anything short of Done means Not Done. I’ve been challenged many times that “the team deserves credit for the effort they put in”, and I respectfully reject this argument. There’s very little value to partially-completed software features that are not usable. Value accrues (and hence ‘credit’ is due) only when an item is complete and usable. Perhaps this is a hard position that some will dispute, but it is the position which in my experience has shown to lead to teams truly focusing on value delivery. Awarding ‘credit’ for incomplete and unusable features simply dilutes the team’s focus on completing everything they committed at the start of the sprint. In fact, I see this sort of watering-down of the Agile Principles as a frequent cause of ‘fake’ or struggling Agile adoptions.

What To Do with Incomplete Stories

Simply put, unfinished stories should go back on the product backlog. Perhaps the Product Owner will prioritize the story for completion in the next sprint, but this should never be assumed or taken for granted. One key purpose of the sprint time-box is to provide frequent opportunities for the PO to re-prioritize and introduce new backlog items. It’s possible that the partial story may no longer be a top priority – it’s the PO’s call either way.

Many teams ask if the story should be re-estimated based only on the work remaining to complete it. I recommend not doing this, as it effectively understates the total effort the story required. This can have negative consequences if you’re monitoring actual delivery velocity over time as an aid to understanding team performance or forecasting future capacity.

Then there’s the idea of splitting the story at the end of the sprint, which invites us to take a ride down the slippery slope. To be sure, I have seen situations where a portion of a story was designed, developed, validated and is truly usable, but the story is not complete and meeting all of the acceptance criteria. If and only if the PO agrees there’s value to be had from the partial delivery, then the team and PO should split the story, accept the completed portion, and place the remaining portion in the product backlog. I simply caution not to abuse this – it would be a very poor idea for instance to split the story into a Design/Build portion and a QA/Accept portion, since the first story does not truly yield complete and usable software.

Why Does This Keep Happening?

Some teams will find this phenomenon of incomplete stories at sprint’s end happening frequently. There are many reasons why teams encounter difficulty completing their sprint backlog, some of which are likely outside the team’s control. To be sure, this is a negative outcome for many reasons, and the team should address the specifics of each and every case during the sprint retrospective. Was the story underestimated, and proved more difficult than anticipated? Was there some external dependency that did not come to fruition, and prevented the story’s completion? Did the team simply over-plan the sprint, and ran out of time to complete everything? Is there an imbalance within the team, for instance more capacity to develop stories than there is to validate and accept the work?

Each of these potential causes suggests things the team can do differently in future sprints to reduce the incidence of spillover. It’s key that the team has the freedom and safety during the sprint retrospective to openly and honestly discuss what happened in each case, without recrimination, and to problem solve together how they can avoid recurrence.

The Real Bottom Line

Here I’ve described the advice I give to new scrums and scrum masters, but I want to emphasize an over-arching principle that can trump all of it. At the end of the day, it is most crucial that the team owns its process. As teams move through their learning journey from Apprentice to Journeyman to Master, they should be empowered to change their practices in the way that works best for them. New teams should look to start by implementing the best practices developed over the last decades, but once they have experienced and experimented with the tried and true, they should be freed to develop their own methods, that respect the Agile principles and deliver great results.