It happens with every scrum team; a sprint ends with one or more unfinished stories. How do we handle the unfinished stories at the end of the sprint? Do we work them in the next sprint? Do we take velocity credit? What can we do better to avoid this in the first place?

Regardless the reasons, unfinished stories offer a wealth of data for the team to better understand what to take into account when selecting stories for the sprint. First and foremost is the opportunity to have a dialog within the team that includes the product owner about what we learned. As a scrum master I get to have the conversation with the team and the wider organization in which I work. We have more than a dozen scrum teams and half as many scrum masters that must work together. Group collaboration across teams is key to building morale and facilitating organization wide planning and forecasting.

I like Tolgay Budayici’s four steps to manage unfinished stories at the end of the sprint. I’ve adapted them for the teams I work with:

  • Identify the stories we won’t be able to finish.
  • Document and estimate the remaining work.
  • Send these stories to the top of the Product Backlog for next sprint prioritization
  • Review the unfinished stories in the Sprint Retrospective

1. Identify the stories we won’t be able to finish

The team needs to do this as early as possible to determine if they need to pull another story into the sprint because of a blockage or something is taking longer than expected. It is also important to give the Product Owner time to reset stakeholder expectations. A key question I like to have teams answer is during the daily stand up is

Will you be able to demo your stories by the end of the sprint?

Asking if a story can be demoed is more powerful than asking if it will be done. Knowing I have to show my work to a group of people encourages a level of thoroughness that may not be otherwise achieved.

2. Document and estimate the remaining work

Now that we’ve identified the stories that will not be finished this sprint we need to document what work is remaining. I call this institutional (the written word) vs. tribal (the spoken word) knowledge. When we want to save our future selves from our past selves we institutionalize our knowledge. Sometimes we humans need a better persistence layer than our memory. Keep it simple, bullet points, don’t overthink it, and have someone else review so that it makes sense to the team as a whole.

Estimate the remaining work so that during sprint planning the team has a sense of what could be accomplished during the sprint. If the original

Should the scrum team get any velocity points for the stories it did not complete?

Our teams have arrived at the conclusion that velocity credit is only earned for the completed stories. Although we have estimated the remaining work we wanted to incentivize a mindset of completion. For the purpose of velocity the work is either Done or Not Done. As a team we want our velocity reflect what we can complete in a sprint.

3. Send the unfinished story to the top of the backlog

The most important question I see is what to do with the unfinished story? A key principle in scrum is the importance of responding to change versus following a plan. Just because we worked on this story last sprint does not mandate we continue it next sprint. While it may be true that 99 out of a 100 times the unfinished story will be carried forward to the next sprint, situations evolve and we want to build a mindset of inspection and adaptation to be comfortable changing direction when needed.

Moving the story to the top of the backlog becomes a forcing function that causes the Product Owner and Scrum Team to reevaluate priorities and ensure the team is working on the top business value at all times. It discourages waste by preventing the scrum team from feeling entitled to roll stories from sprint to sprint.

4. Review the unfinished stories in the Sprint Retrospective

Using the retrospective is the time when the team explores what prevented them from finishing a story. It’s important to emphasize the team did not complete the story. The team is committing to the sprint. It is the team’s joint responsibility to complete the sprint. Keeping the discussion team oriented minimizes finger pointing and the potential shame some developers may feel for not competing something they felt on point for delivering.

Keep it short and look for recurring patterns the team can address. We noticed our peer code reviews and testing steps often kept stories from completing during the sprint. It a great opportunity for team process improvement.

Read more suggestions on handling unfinished stories at