How is the sprint review different from the sprint retrospective?
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.
What happens during a sprint review?
The entire development team, the Scrum master, the Product Owner, and the key stakeholders are present during the sprint review. The Product Owner explains how much of the sprint goal they were able to accomplish. The team demonstrates the stories and tasks they completed and discusses the incomplete ones, as well asthe hurdles they faced. The review for a month-long sprint typically takes 4 hours.
The stakeholders act as the end user and interact with the increment, raising any questions they may have. It's crucial that the key stakeholders be present during the sprint review as this is an important point in the development process for their interests to 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. The potential capabilities, release timelines, and budget of the product are also reviewed. The sprint review offers valuable input for the next sprint planning meeting.
4 best practices for your sprint review
Define your "done"
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."
Keep it casual
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.
Involve your PO
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.
Celebrate small wins
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 the 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.