STEP 13
Sprint Review
1
MYTH-
It’s expected that a team will demo a feature even if they didn’t finish it in the sprint.
At the beginning of Sprint Planning, teams should mention the PBIs to which they committed but did not finish (if any). This is to maintain transparency with the organization through the product owner. While a feature may be very close to being done, it should not be demoed in this meeting unless it meets the team’s Definition of Done (DoD).
2
FACT-
The Product Owner accepts a feature based on the conversations and acceptance criteria that was previously discussed with the team, not by some criteria the team hasn’t heard before.
The team can only be responsible for building functionality that has been described in PBIs and through conversations with the Product Owner. PBIs that were completed based on that information should be accepted. New functionality or requirements the PO would like to see in a feature should be added to the Product Backlog for future development.
3
FACT-
Stakeholders are welcome at the review as long as they don’t interfere. Their feedback can be helpful for shaping the product moving forward.
Feedback from stakeholders is important to a product’s health, and it can be helpful for them to see features demoed as they’re completed so that they can give feedback to the Product Owner.
4
MYTH-
Teams should spend at least 4 hours preparing for the review, and the review should include PowerPoint slides.
Preparing for a Sprint Review shouldn’t take long, and there’s no need for special artifacts like PowerPoint slides. The meeting is simply to demonstrate working software. The software written to complete the PBIs is all that need be shown.
5
MYTH-
If the team can’t demo a feature because it wasn’t completed, it’s okay for a manager to question the team’s approach in this meeting.
If a team didn’t complete an item to which they committed, they’ll feel bad enough for not having done what they said they would. Having a manager browbeat them in public is one of the quickest ways for a team to lose trust in the organization. Self-organizing teams don’t need this type of feedback. Any coaching a manager may have for the team can be shared in more constructive ways that are not damaging to self-organization.
6
MYTH-
The Sprint Review is mainly for show and has little impact on the product.
This meeting is one of the important inspect and adapt loops in Scrum. While the development team and the Product Owner should be communicating often during a Sprint, and the PO should be talking with Stakeholders during the sprint as well, this is a formal meeting to ensure the PO and Stakeholders get to see the progress made in the sprint. While features originally outlined in the Product Backlog are a good start to getting everyone on the same page, nothing speaks louder than working software. Often, seeing a feature ‘live’ will spur new ideas or course corrections that end up as new items in the Product Backlog.
7
MYTH-
A manager should pick who does the demos during the Sprint Review.
The Sprint Review is run by the team. As such, the team should chose who demos which features.
8
FACT-
Feedback from stakeholders during the Sprint Review should be collected and put on the backlog for consideration by the Product Owner instead of spawning long conversations during the review.
The Sprint review is not the place for debates over what was (or is to be) built. The Product Owner is the only person who can accept or reject work, and it’s his job to work with stakeholders to define features and acceptance criteria. This should be done when creating the original PBI, not during that PBI’s demo in Sprint Review.
9
MYTH-
Most Sprint Reviews only last 10 minutes.
During a Sprint Review, features should be fully demoed, and the team should show the PO how each of the acceptance criteria were met. This can take an hour or more during a two week sprint.
10
MYTH-
The Scrum Master should be in charge of running the Sprint Review and making sure the team demos what they need to demo.
he team is responsible for running this meeting. While the Scrum Master can facilitate the meeting, it’s up to the team to make sure demos are done.