What to do when a user story is 'undone'

We’ve been coaching a few new Teams to use Scrum and it’s interesting to see the similarities continue to pop-up, particularly around estimating how much the Team can complete in a Sprint, and then what to do when a User Story doesn’t get completed. So what do you do when the User Story gets more complicated half-way through and, as a result, can’t be completed in the Sprint?

1. Put it back into the Product Backlog

Unless you’re using continuous flow from Kanban and Lean, a User Story doesn’t get allocated to the next Sprint. It simply returns to the Product Backlog. From there, the Product Owner will assess whether it’s still of business value to complete and will order it accordingly.

2. Don’t reap the Story Points for this Sprint

As the User Story was not completed, the Team simply doesn’t gain any of the Story Points. There are some thoughts that suggest partial-credit should go to the Team for the work that was done, but there seems to be a general consensus amongst Scrum thought-leaders that this can lend itself (consciously or otherwise) to gaming the numbers.

3. Re-estimate the remainder of the complexity of the User Story

When it comes time for Sprint Planning, the Team should then re-estimate the User Story based on:

  • Why the User Story was left undone
  • The new things they’ve learned about the User Story
  • The new tasks and/or requirements of the User Story
  • The remaining complexity, not the whole story including what was Done

Specifically, this approach ensures that the Team’s velocity isn’t skewed by the inflation of effort already spent.

4. Working with Jira/Greenhopper

Just changing the Story Points for a User Story in Jira may lead some people viewing the Boards that the effort of any nested sub-tasks are worth less than they are. All sub-tasks in Jira are independent of their parent User Story so it’s no effort to leave one sub-task in one Sprint, classify it as completed, and move the User Story into a new Sprint (along with any new tasks) when the Product Owner places it high in the order of the Product Backlog and Team commit to doing it in a subsequent Sprint. Some of the history, though, of what happened that may be important should be recorded.

  • Make a comment against the User Story of its original Story Points
  • Note the lessons learned from the Retrospective as to the over-estimation

It’s clear to see from the Transitions tab of the Activity panel that a User Story has been opened and then gone back into the Product Backlog.

The History tab also shows any changes to Story Points.


Keeping the process for undone User Stories as simple as possible ultimately reduces the likelihood that the Team will develop additional bad behaviours that will adversely impact the Scrum. This process reduces the likelihood of gaming and ensures everyone understands that Story Points can only be reaped once the User Story is actually Done, and not before.

Matthew Hodgson

Matthew Hodgson

Founder of Zen Ex Machina. Scrum/Agile Coach. Designer of digital experiences since 1992. International presenter. UX & psych geek. Chocoholic. Loves red wine.

Related Posts:

Leveraging learnings from across the enterprise to upskill and accelerate capability development

This was the fourth attempt at this critical project for our client so the spotlight was on.

Read More

Increase transparency to reduce scaled-agile risk

One of the biggest advantages stemming from good scaled-agile practice is the benefit of enhanced transparency. This helps to manage and reduce risk.

Read More

Improve feedback with a Feedback Dojo

To achieve positive changes in behaviour feedback needs to come from a foundation of trust, delivered at the right time, in a private space.

Read More

Copyright © Zen Ex Machina® and ™ (2019) All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close