The Agile Mindset Blog

The Dangers of “Roll-Over” User Stories

The Dangers of “Roll-Over” User Stories

There are inevitably going to be times when a Scrum team commits to deliver a user story and they do not complete it. So what happens next?

The Product Owner rejects the story. It goes back to the Product Backlog and can be prioritized wherever the PO would like it to be.

It does not roll over to the next sprint. It is rejected.

There are only two states a committed story can come out of Sprint Review in: accepted or rejected. There is no such thing as a “roll-over story” in Scrum.

“Isn’t this just semantics?” you might say. “The PO is probably going to have the team work on it in the next sprint so what does it matter if we call it ‘rejected’ or ‘rolled over’?”

The reason it matters is due to the habit you are building in your teams. As soon as a team member can say to their PO “Oh, don’t reject our story because we worked really hard on it and that will mess up our velocity. Just roll it over and we’ll finish it next week” they have missed the opportunity to figure out why they clearly did not understand a user story they thought they did.

Instead, the PO should reject the user story and, in Retrospective, the team should talk about what they will do differently in the future to ensure they will better understand committed stories. This is the only way we learn from our mistakes - to face them and figure out why they happened.

Teams that soften their rejected stories by calling them “rolled over” tend to have lots and lots of rolled-over stories. Of course they do. They never got a chance to figure out why they didn’t deliver. When you let teams roll over stories you are condemning them to make the same mistakes over and over again.



  • This is exactly what happened in our team. We started letting teams roll over stories because it made it easier in our software tool. But within a short time it seemed like pretty much every story was getting rolled over. We started calling stories rejected and moving them back to the backlog, then talked about what went wrong in retrospective. Magically, more stories ended up being truly done at the end of the sprint!
    1/25/2022 1:14:45 AM Reply
  • Yes! Stories have 3 states - Backlog, Sprint, and Done. Retrospectives are so often overlooked or given lip service and velocity (skill) isn't measured or managed -'we didnt quite understand that story, it was bigger than we thought' OR 'I didnt think it would be so hard to implement' OR 'there was a thing I've never used before, I needed to learnt that thing first' These are all critical questions to answer in a retrospective. Which implies there is nothing wrong with a rejected story. Its part of the process - its not failure, its an opportunity to learn. Once the scrum team (and Product Owner) gets over this philosophical hurdle you may find velocity naturally increases.
    5/13/2020 11:18:00 PM Reply

Post a Comment