Do those un-delivered User Stories at the end of a Sprint really need rolling?

It is a mistake to continually roll unfinished User Stories from Sprint to Sprint. Instead pay attention to them and consider what is going on.

When prioritised backlog items have not been completed during a Sprint it is worth taking a look at them at least to find out if they are still required, correctly annotated and have useful Acceptance Criteria.

Rolling unfinished items “automatically” can use up a significant amount of bandwidth in the next Sprint, blocking other potentially more highly prioritised items.

The first step should always be to check with the Product Owner who should be able to make the decision on whether to roll, park or seek further elaboration which may require a re-write of either the User Story of the Acceptance Criteria.


Another option for the Product Owner and team is to split a User Story into smaller pieces, although if the sizing had been done correctly up front this should not be needed, unless new information has come to light, especially if a third party is involved.


If a User Story is rolled or parked, the team will not be credited with the Story Points which can affect their Velocity. This is not necessarily a bad thing as it reflects the reality of what’s happening. Perhaps an Agile Coach is required to help the team(s) with sizing and engagement with Stakeholders to better define the Definition of Done.


The aim of any Agile Team is to deliver the outcomes required and prioritised by the Stakeholders. The wrong thing to do here is to blindly throw resources at a User Story proving difficult to close out, without escalating. It may be the case that a User Story can be cancelled if it begins to roll without a clear end in sight.

Got a Question? Ask Agile Unpacked…

At the End of a Sprint

Along with a Retrospective, the end of a Sprint should result in a useful & readable update for Stakeholders

It is not enough to close a Sprint, have your Retrospective, roll any incomplete User Stories, close the Sprint in JIRA and open the next.

Stakeholders need to be updated in a clear, consistent and useful way on the outcome of each Sprint.

High Level Sprint Summary

Before any detail is articulated it is useful to summarise a Sprint in an easy-to-consume fashion. I have found that a simple table is of most use which can ideally be standardised across Agile teams.

This may include Velocity and/or Burn Up (more on that on another post), as well as Average User Story size, percent complete (for User Stories and Acceptance Criteria) and percentage of User Stories rolled to the next Sprint with any headline reasons.

Product Progress

At a high level it is useful for Stakeholders to know which products (whether technical or business relates) have been furthered by the Sprint and which have not.

Epic Progress

As products can straddle more than one Epic, it is useful also to report back to Stakeholders what progress has been made tracing back to a User Story’s Epic. This will help Stakeholders understand how accurate their sizing has been.

User Story Progress

This may include completed User Stories and their contribution to the development of products. At a more granular level some Stakeholders may want to see the progress of each User Story which has been rolled into the next Sprint. For example a User story may have been sized at 5 days and four days have been completed vs. the Acceptance Criteria. There’s a big difference between saying User Story 123 has rolled, and User Story 123 has been rolled at 80% because of an external dependency.

Got a Question? Ask Agile Unpacked…