Your team has just completed a sprint – a timed working session where an entire team comes together to work through a set of product backlog tasks. Now that the sprint is over, it’s time to review all the work your team came together to complete. This happens in a Sprint Review Meeting.
During the sprint review meeting, scrum team members give informal presentations of their respective completed deliverables, often in the form of a software or product demo, and get feedback on the developments from relevant stakeholders.
Sprint review meetings are intentionally kept very informal, with many organizations setting rules forbidding the use of slides and allowing less than two hours to prepare for each sprint review. Attendees of sprint review meetings commonly include the scrum team and scrum master, development team, and product owner, as well as designers, writers and analysts. The scrum master is tasked with facilitating each sprint review meeting and making sure the participants understand the purpose of the event.
Sprint review meetings should happen within 48 hours of completing a sprint cycle, and usually last 1-2 hours, depending on the number of sprint tasks to be reviewed. A general rule of thumb is to alot one hour for each week of the sprint, therefore a two-week sprint would have a two-hour sprint review meeting.
What’s inside this Sprint Review Meeting Template:
To help you effectively incorporate review meetings into your team’s sprint process we’re sharing our agenda template and best practices for sprint review meetings.
1 Sprint goals
The first few minutes of every sprint review meeting is spent evaluating the goals that were set for the last sprint as a reminder of what your team hoped to accomplish, before reviewing the work that was done. Often these goals were established based on a user story or ticket, and usually address a development challenge or user need.
2 Completed tasks
Once everyone is refreshed on the goal, the sprint task list is reviewed by the product owner to determine which tasks are complete by giving a brief “done” or “not done” update. Ideally, the team has completed each product backlog task brought into the sprint, but it’s more important that they achieve the overall goal of the sprint.
3 Demos from development team
The next portion of sprint review meetings is spent reviewing demos from the development team. During this time team members demonstrate a working model of the software to the rest of the sprint review meeting attendees.
Demo presentations should last five minutes each, and be designed to address which tasks have been completed, which new features were added and what bugs have been fixed. The demo isn’t just about proving that the software works, it should also demonstrate the business value that it provides customers.
The demo portion of the meeting is also a great opportunity to celebrate the hard work and accomplishments of the scrum team during the sprint. Effective sprint review meetings should build up the morale and motivation of the team.
4 Feedback from stakeholders
During the demos, the stakeholders attending the sprint review meeting assess the presentations against the original sprint goal and provide any feedback they may have. The demos are evaluated on whether or not they meet the users’ needs, create value, account for internal dependencies, and improve functionality. It is common for a product that was presented to go through multiple development iterations based on the feedback from sprint stakeholders.
5 Key metrics
Following any stakeholder feedback, the team reviews the key metrics, or measurable outcomes, they’re working towards and determines whether or not the solutions they’ve demonstrated will move these metrics towards the target or goal. Key metrics typically include goals around improving functionality, driving customer behaviour or increasing user engagement.
The last portion of your sprint review meeting should be spent evaluating the backlog, any remaining tasks, and determining next steps. If there are any backlogged tasks, the project owner predicts the likely target and delivery dates based on progress to date. Tasks that are backlogged often become the focus for future sprints, and are moved to a sprint planning meeting agenda.
If there aren’t any backlog items, the team may begin discussions on other future sprint goals, market demands, potential capabilities or products in the pipeline.
Frequent sprints and sprint reviews ensure team alignment on development goals, and allow sprint teams the opportunity to quickly identify issues and course correct before pushing a product to development, saving time and money.
We hope this sprint review meeting agenda template helps your team better analyze your sprints, improve your development processes and build a culture of delivery in your organization!