At the end of each sprint, there are two meetings held: the sprint review and the sprint retrospective. The sprint review's purpose is to inspect the increment that was developed in that sprint and collect feedback from key stakeholders. The sprint retrospective is to inspect and improve the agile practices that were followed during the sprint. Both are distinct and essential for a Scrum team to function well.
A sprint review is a collaborative meeting that is typically held at the end of every sprint. This is when the team runs through work items they completed during the sprint or iteration. A sprint review ensures key stakeholders are up to date, and it enables them to provide feedback. At the end of each sprint review, the product owner or the team lead uses this feedback to create necessary work items in the product backlog.
While sprint reviews do not have a mandatory prescribed structure per se, they have certain components that tend to be consistent across organizations and teams.
During a sprint review, the entire development team, the scrum master, the product owner, and the key stakeholders are present.
The product owner explains how much of the sprint goal they were able to accomplish. Team members demonstrate the stories and tasks they completed and discuss the incomplete ones, as well as the hurdles they faced. The review for a month-long sprint typically takes four hours.
The stakeholders act as the end user and interact with the increment, raising any questions they may have. It's crucial that stakeholders are present during the sprint review, as this is an important point in the development process, and their interests should be represented.
The product owner discusses the current state of the backlog and the project's delivery dates, incorporating the state of the market, technology, and the latest feedback.
Lastly, the potential capabilities, release timelines, and budget of the product are reviewed. The sprint review offers valuable input for the next sprint planning meeting.
The sprint review frequency depends on the below criteria:
The core sprint review purpose is to enable the team to collect feedback on the work items that have been completed during a sprint. It also helps them evaluate how well they have performed as a team. With feedback, the team can verify whether they are meeting stakeholder requirements, understand any changes that need to be made, and decide what will remain the same in upcoming sprints. The sprint review contributes to a transparent process and ensures the team meets expectations.
During a sprint review, the team presents work items that are "done." Is your user story finished once it's developed and tested in the local environment, or is it really done only when it's in production? It's important to make your definition of "done" clear because there's no purpose in the team demonstrating software that hasn't been tested or isn't "potentially shippable."
Sprint reviews are usually informal. Slideshow presentations are a big no-no. Instead of slides, present your working software instead. The tone of the meeting can also be conversational, following which the discussions become more friendly and the feedback is more welcome.
The product owner is a part of the core team and should be involved with all stories and tasks the team is working on. In some teams, the product owner even presents the software to the stakeholders. It's not a good sign if the product owner is getting their first demo of the software along with the stakeholders during the review meeting.
The sprint review meeting is not just a demo opportunity or a place to get feedback. It's crucial to use this meeting to celebrate anything the team has accomplished in that sprint. The increment is a small step towards the goal. It adds value to the product, and celebrating small wins is a great way to boost morale within the team.
If your team doesn't have demo-ready software at the end of the sprint, it could be an indication that you're taking on more than you can chew or that your goals changed mid-sprint. Feedback and insights are key players that drive an agile team forward. Sprint review meetings are the place to inspect and adapt your product, along with getting feedback from stakeholders and potential end users. This makes the sprint review an important meeting in the Scrum process. It ensures your process stays agile.
If your team doesn't have demo-ready software at the end of the sprint, it could be an indication that you're taking on more than you can chew or that your goals changed mid-sprint. Feedback and insights are key players that drive an agile team forward. Sprint review meetings are the place to inspect and adapt your product, along with getting feedback from stakeholders and potential end users. This makes the sprint review an important meeting in the Scrum process. It ensures your process stays agile.