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.