The Rollover Hazard: Why Rolling Over User Stories Shouldn't Be Routine

Evelyn Tian
Whether in mentoring sessions, organizational coaching, or training, questions like these come up: “If a user story isn’t completed in the current sprint but finishes in the next one, how do we account for the story points? What if a user story is only completed after three sprints? How do we calculate velocity then?”

While these are valid questions, they point to a deeper issue: why rolling over at all?

In this blog, we will discuss why I call rollover a hazard and how to prevent it.
The Rollover Hazard: Why Rolling Over User Stories Shouldn't Be Routine

The practice of “rolling over”, or “spill over" user stories—carrying them from one sprint to the next when unfinished—frequently sparks discussion. Whether in mentoring sessions, organizational meetings, or training, questions like these come up: “If a user story isn’t completed in the current sprint but finishes in the next one, how do we account for the story points? What if a user story is only completed after three sprints? How do we calculate velocity then?”

While these are valid questions, they point to a deeper issue: why do we experience rollover 


Hence, before we look at how to handle user story rollover, let’s explore why it happens and whether it’s beneficial for the team’s workflow.
Why Do User Stories Roll Over—and Why Does It Matter?

If, during a sprint, developers realize that a user story can’t be completed, the team’s first action should be to communicate with the Product Owner. Together, they can determine if the story can be divided into smaller, achievable parts. This approach allows the team to deliver part of the value in the current sprint, avoiding the buildup of incomplete work.

However, if it was unpredictable that the story would remain incomplete, the story should ideally return to the product backlog. The Product Owner can then reassess its priority, deciding whether it should be completed in the next sprint or deprioritized based on updated insights. There is no strict rule that an unfinished story must roll over to the next sprint. In fact, routinely rolling over stories can create bad habits, as the team may lose the sense of urgency and focus needed to meet sprint commitments.

The Impact of Frequent Rollover: When Rollover Becomes a Pattern

In some organizations, rolling over user stories becomes habitual. As a result, discussions tend to focus on how to distribute story points for rolled-over stories instead of addressing the underlying issues that cause rollover.

A better question to ask would be: How can we prevent the need to roll over user stories?

Agile teams should aim for iterative, incremental progress, delivering value early and often. By focusing on completing user stories within the sprint, Agile teams can reliably create value and avoid the delays, frustration, and loss of momentum that come with rollover.

Benefits of Reducing User Story Rollover

Minimizing user story rollover enhances Agile team effectiveness and predictability, leading to:

Consistent Delivery of Value: When teams reliably meet their sprint goals, they build trust with stakeholders and reinforce their reputation for delivering on commitments.

Improved Team Morale: When user stories are completed each sprint, team members experience a sense of accomplishment, reducing frustration and burnout. This sense of achievement fosters motivation and positive momentum.

Enhanced Product Quality: Teams that minimize rollover can focus on technical quality, managing technical debt, and delivering with excellence rather than being distracted by unfinished stories.

A Stronger Mindset of Value Creation: Completing stories within a sprint encourages teams to prioritize value creation, delivering increments that matter to the business and users.

Handling the Rare Instances When Rollover Is Inevitable

In some cases, despite best efforts, a story might take more than one sprint to complete. When this happens, story points should only be counted in the sprint in which the story meets the Definition of Done. This approach keeps the team focused on quality and value creation.

For planning, the team should look at velocity trends across recent sprints, using averages to guide predictions. This method accounts for natural fluctuations in team speed and provides realistic forecasts.

Building a Roll Over Protection System (R.O.P.S.)
As many of you know about my experience with automotive industry, Volvo has been putting their efforts to proud about their heritage of safety innovations, and their R.O.P.S. 

Borrowing their concept, we should also have a R.O.P.S. in place for our Agile product development, and prioritizes Value Creation Over Rollover

Avoiding user story rollover is about more than accurate story point tracking—it’s about cultivating a disciplined, focused Agile team that delivers value continuously. By improving sprint planning, enhancing collaboration, and maintaining clear priorities, Agile teams can meet their sprint goals more consistently, delivering value on schedule and sustaining momentum.

Reducing rollover helps teams stay aligned with Agile principles, improving predictability, fostering a sense of achievement, and building a culture where value creation is always top of mind.

I hope that in future sessions, I’ll hear more questions about how to create value faster, rather than how to manage rollover situations.
Empty space, drag to resize
Write your awesome label here.

Join our community

Thank you!
We have supported practitioners from 80 countries, and have monthly free activities for our community members.

You can bring any topics to our activities, or just get ready to network.
Created with