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.

About the author

Related Posts:

How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).


Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.


How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.


How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.