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…