Welcome to the Sprint Review, where the sprint ends, and the developers are trying to convince everyone that ‘Done’ means ‘perfect‘, even if it still sounds a bit like ‘in development‘ 😄
The Sprint Review is a Scrum ceremony that takes place at the close of each sprint. It represents the work undertaken during the sprint planning. It has several objectives, including:
- Review the work done during the sprint in the presence of the Product Owner and Key Users.
- Present the results obtained at the end of the sprint.
- Promote exchanges and discussion between the different teams involved in the project.
- Empower the development team by encouraging them to present the work they have done.
- Get immediate feedback from stakeholders.
Key Points
This article on the Sprint Review will reveal the right moment to hold it, the key players involved, the essential phases of the process, and will conclude with a series of recommendations and practical tips .
When Should You Do the Sprint Review?
The main elements of a sprint review are:
Frequency
On the last day of each Sprint and just before the Retrospective.
It’s important to maintain the regularity of the Sprint Review by holding it at the end of each sprint, which helps maintain an efficient workflow.
Duration
Maximum 1 hour per week of Sprint. But beyond 2 hours, it can be complicated:
- To have the end users.
- To maintain motivation and focus.
Inputs
The inputs of the Sprint Review mainly include:
- Product and Sprint Increments : User Stories and tasks performed during the sprint.
- Acceptance Criteria : The criteria defined for each element of the sprint.
- Documentation : Any relevant documentation, such as test reports or technical specifications.
- Kanban Board or Tasks: Updated Kanban boards or individual tasks.
Outputs
The outputs of the Sprint Review include:
- Feedback & Comments: Feedback from stakeholders, including the Product Owner, on the features presented.
- Possible changes to the Product Backlog: additions, modifications, or deletions of items from the Product Backlog.
- Validation of sprint objectives: confirmation that sprint objectives have been met, or adjustments if necessary.
Agility: More Reading
Who Participates in the Sprint Review?
Stakeholders :
Assesser
Such as key users, company members or customers, can be invited to the Sprint Review to review the results and provide feedback.
Dev Team
Implementers
The team that worked on the features and work items of the sprint is present to present the User Stories carried out and demonstrate the work accomplished.
Product Owner
Sponsor
The Product Owner, as the representative of the stakeholders and the the product vision holder, is essential to evaluate the developed features and provide feedback.
Scrum Master
Facilitator
The Scrum Master facilitates the Sprint Review, but he is not an active participant in the sense of providing feedback on the work done.
Business Analyst
Contributor
The business analyst can provide expertise in business needs and specifications. His participation can help ensure that the developed feat ures align with the business requirements and product objectives.
QA Lead
Contributor
The QA manager can review the developed features from a quality and standards compliance perspective. Its presence can help identify potential quality issues and ensure that the work performed meets the acceptance criteria.
Example of a Three-Step Sprint Review: Prepare, Present, and Feedback
Prerequisite
The day before the Sprint Review , set aside a time slot to run the presentation scenarios on an integration server and make sure the application is bug free.
Step 1: Preparation (15 minutes)
15 minutes: to review/prepare the following items:
The Scrum team prepares by considering scenarios to present the different User Stories that have been implemented in the Sprint increment. It’s important to note that only User Stories that are considered ‘Done‘ are included in the increment.
The team checks that all the equipment needed for the demonstration is operational (Connection, Projector, Board, etc.). etc)
It calculates the true velocity by adding up the Story Points associated with the ‘Done‘ features.
Important!
A partially completed feature doesn’t earn any story points because it’s not yet usable.
Step 2: Demonstration (45 minutes)
45 minutes to go through the application presentation following this template:
- The Product Owner starts by reiterating the purpose of the Sprint.
- Next, the Scrum Team presents the indicators of the Sprint, including:
- KPIs such as burndown chart, Sprint velocity, comparisons to initial engagement at the beginning of the Sprint.
- a review of the User Stories considered ‘Done‘, as well as the highlights of the Sprint that can help explain the results obtained.
- The development team takes over by presenting the functionalities considered as ‘Done‘ and engages in an exchange with the stakeholders.
Step 3: Feedback (15 minutes)
15 minutes to gather user feedback.
The Product Owner and Stakeholders provide feedback to the development team.
It’s important to note that the Product Backlog can be updated based on this feedback.
The role of the Scrum Master is crucial at this stage, as they must guide stakeholders to give constructive and positive feedback.
Finally, the Product Owner makes the decision to accept or reject the presented features .
Step 4 (optional): Adjust the Release Plan
The completion of this step will depend on the project team's assessment of its importance.
- Analysis of global project indicators :
- Average velocity, velocity evolution, cumulative Burn Down Chart…
- Analysis of the condition of the Product Backlog
- Especially following user feedback and possible new needs integrated into the Product Backlog during the Sprint.
- Based on these elements, check if you need to update the Release Plan.
- Stakeholderss are involved in this step, in order to strengthen transparency and trust.
- If a minor update to the Release Plan is necessary, to do it in session. If further discussion is required, schedule a dedicated meeting.
- In all cases, confirm the Release Plan to the Stakeholders.
Tips and tricks
Congratulate the team
Congratulating the whole team at the end of the sprint review gives a sense of appreciation and recognition for the effort made during the sprint.
What and not how
Focus on ” what we did” rather than ” how we did it” to avoid technical considerations that unnecessarily burden the Sprint Review.
Blank review
If the team is not comfortable, organize a mock review before the sprint review.
Fitting
If possible, let the Product Owner and end users try the product themselves.
Captivate attention
Using a storytelling or scenario approach can be captivating, as it allows each business rep to identify with the use of the product.
Empowering the team
Prioritize the management of the meeting by the team members to share responsibility.
Focus on what works
Ignore what doesn’t work and focus on demonstrating what code works.
Clarifying the Purpose
Before diving into the Sprint Review, be sure to clarify the purpose of the Sprint. If attendees are unfamiliar with the product, take a few minutes to give them a brief introduction. This will ensure a common understanding and a more productive meeting.
0 Comments