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.

Conclusions

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.
M

About the author

Matthew Hodgson

Matthew is the CEO and co-founder of Zen Ex Machina (ZXM) - an organisation dedicated to improving people's working lives through contemporary ways of working. Matthew is an author, keynote speaker and and a regular presenter on the international agile conference stage in Australia, USA, Asia and UK. He's highly regarded amongst his clients and peers for the unique approach he has brought to the industry focussing on scaled agile using organisational psychology, change and culture.
Matthew is a Professional Scrum Trainer (PST), SAFe SPC, Certified Agile Leader (CAL-1), Certified Scrum Professional Product Owner and Scrum Master (CSP-PO and CSP-SM), and a certified Lego Serious Play facilitator.

Related Posts:

If your an agile coach, just knowing Agile, or Scrum, or how to set up a Kanban board won’t be enough to get you though the complexities involved in successfully performing the role and being an agile leader. Seek to expand your knowledge and capabilities and practice intentionally as part of your own continuous improvement.

What governance best supports product development efforts using agile frameworks? Don’t be tempted to over complicated things with a hybrid committee structure. Scrum has all the roles and responsibilities you need to deliver value.

Scaling is challenging and one of the key reasons agile initiatives fail is that the culture of the organisation is at odds with agile mindset and agile principles. But the next key factor is management support. So we knew that this change needed to be driven and supported by the leadership team in order to be successful.

Every executive is familiar with the hours long weekly meetings where senior leaders report to the CIO. When the world is rapidly changing and whole divisions work remotely, comprehensive formal reports are good but outdated by the time they’re written.