Scrum Events : Sprint Review
The Sprint Review is the point where the scrum team and stakeholders Inspect and Adapt the product
The sprint review meeting is the 2nd to last event in the sprint. It is generally regarded as being open to all stakeholders. Meeting duration is time-boxed to and maximum of two hours for a two-week sprint, or four hours for a one month sprint.
The Sprint Review meeting supports the following principles and concepts:
- Working software is the primary measure of progress.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
DevOps 2nd Way: Shorten and amplify Feedback loops
The sprint review is a structured conversation where we do three things:
- Demonstrate the product increment
- Assess the sprint stories for being ‘DONE’
- Seek stakeholder feedback on changes
1. Demonstrate the product increment
- In the sprint review the development team demonstrates to the product owner the working software that relates to each committed story, working from the top priority item down.
- The activity is not a celebration of success, it is the ‘inspect’ step for the delivery working software.
2. Assess the sprint stories for being ‘DONE’
- The Product Owner, at their sole discretion, decides whether or not each Product Backlog Item meets the definition of ‘done’ and if so moves the item to ‘done’
- If they decide it is not done, the Product backlog Item goes back – in its entirety - into the product backlog for re-prioritisation against all other items
- This process can happen in a number of ways
- During the course of the sprint
- After each Product backlog Item is demonstrated
- After all Product backlog Items inthe sprint have been demonstrated
- However it happens the demonstration should still occur as this is the empirical evidence of working software in operation
3. Seek stakeholder feedback on changes
- Once the sprint backlog has been cleared, either into DONE or returned to the product backlog, stakeholders are only then asked for their feedback on any changes they now have for the product
- This is the ‘adapt’ step in the sprint cycle, for the identification and capture of new (emergent) requirements
- The sprint review is a demo of actual working software, not a report on how the sprint went, PowerPoint slides, or design documents
- Only items that are fully DONE are marked as DONE and counted in velocity, there is no concept of a partially DONE item
- Stakeholder feedback happens last, after the mechanics of assessing the sprint are finished with.