How to handle unfinished user stories at the end of the Sprint?

How to handle unfinished user stories at the end of the Sprint?

“What do we do with unfinished work at the end of the Sprint?” – Eavesdropping on colleagues walking toward the lunch room 😅

Often there will be work – user stories – that is left un-“done” at the end of your Sprint. Even with the best intentions of integrating your work regularly. And what should happen to that unfinished work? Do you just continue working on it during the next Sprint? Do you spend time on these tasks during the Sprint Planning? Do you make it transparent to the team? …

How to handle unfinished user-stories

Transparency, Inspection, Adaption

I’ve worked with several teams that don’t reconsider the work in progress and automatically transfer it to the next Sprint. During the Sprint Planning that unfinished work is never mentioned and a new Sprint is planned full of new features. It always stings to see great teams run an excellent Sprint Planning meeting just to find out that no one is actually working on what they had just planned a few moments earlier: “Oh, I’m first finishing up some things from last Sprint.” STOP! The last Sprint is over. Timebox ended! We are in the next Sprint.

Before going into your next planning, the best practice is to move all the unfinished work from the Sprint Backlog back to the Product Backlog. Make it a conscious decision whether the team continues, some or all, of the unfinished work in the next Sprint or not, negotiate this with your Product Owner. Make it transparent what the impact of the unfinished work is by treating these items like any other items you discuss: clarify the remaining problem you aim to fix, the unrealized value, possibly estimating the remaining effort, and collaborate on what to do and how to do it.

For example, it could happen that the team discovers that the remaining work is of little value to their stakeholders and that any additional time spent would be wasted by over-engineering the solution. Always try and maximize the work NOT done! Or it could be that several items are close to getting done and have a high potential value and should be finished first. Leaving less room than expected for new items. Better to realize this at the start of a Sprint than to get surprised at the end.

Scrum stands on the three pillars of Transparency, Inspection, and Adaption. My advice is that you apply these pillars to the unfinished work as well. Be transparent about the state of the work, inspect its effort and value, and adapt the plan toward maximizing value for your end users.


You might also like

VIDEO

A real Sprint Review meeting

Get a peak at a real Sprint Review meeting with a Scrum team from Skyline and key stakeholders from the Finnish broadcasting company YLE.

BLOG

Do you have to answer “the three questions” during every Daily Scrum?

How do you achieve the purpose of a Daily Scrum without utilizing the “three questions”?

2 thoughts on “How to handle unfinished user stories at the end of the Sprint?

  1. Pieter Van Compernolle

    Totally agree, nobody is proud of having ongoing work at the end of the sprint (developers typically experience it as they didn’t really finish up, while stakeholders experience it as ‘it’s almost done’, no need to discuss further, …)
    Nevertheless, it’s super important to take the ongoing work as a fixed topic in your sprint planning and also inspect it during your retro.
    Thx for highlighting this Bram!

Leave a Reply