Learn About Agile
The sprint review is an inspect and adapt opportunity that occurs at the end of each sprint. The purpose of a sprint review is to gather feedback on (inspect) newly added features. Review participants then discuss the implications of the features and feedback on the product backlog and project schedule, which influences what will be built next (adapt).
For example, based on feedback, a product owner may elect to release the current version rather than wait a few more sprints as originally planned. Or the product owner may decide to hold off on releasing to improve the newly added features a bit. Similarly, stakeholders may love some aspect of the recently developed features and want that carried into other parts of the product.
What Happens in a Sprint Review?
A sprint review meeting is held at the end of each sprint. During this meeting, the scrum team demonstrates what they accomplished during the sprint. But the sprint review is more than just a demo. (Check out this example sprint review agenda.)
Sprint reviews are timeboxed to a maximum of four hours for a one-month sprint. For shorter sprints, sprint reviews can be accompllished in an hour or two. The sprint review meeting is intentionally kept very informal, typically without slides and with minimal preparation time for the meeting. Sprint reviews should not become a distraction or significant detour for the team; rather, they should be a natural result of the sprint.
Sprint Review Participants
Participants in the sprint review typically include the product owner, the Scrum team, the Scrum Master, plus stakeholders, including management, customers and developers from other projects.
Sprint Reviews: What to Show
During the sprint review, the team gets fast feedback from the participants on items they completed during the sprint. A team only needs to show the work they did that enables this conversation.
As a trivial example, consider a bug fix made during the sprint. I participated in the review of a team that had fixed a bug involving the display of U.S. dollars. The team hadn’t truncated the number to only two decimal places. In one case a discount was shown as 3.71428571 dollars.
As soon as they discovered the bug, someone quickly fixed it, and someone else verified the fix. So far, so good. But then they demonstrated this at the next sprint review.
Don’t do this. No one needed to see that. Mention it if you want. Say, “and we fixed the bug where dollars weren’t being truncated after two decimal places on the such-and-such screen.” But don’t waste time showing that unless someone specifically asks to see it.
I like to start each review by sharing a simple agenda. If we’re together in a room, I’ll project it or possibly pass out printed copy. If we’re meeting online, I’ll share my screen.
The agenda is simply a list of the product backlog items the team will show during the review and a second list of ones they will not show. The 8-digit dollar values I just mentioned would be on the not showing list.
I want to be clear that a team isn’t doing this to hide anything. And if a review participant asks to see a feature on the list not to be shown, the team should happily show that feature. This happens most commonly when a meeting participant says something, “Which screen had the problem with all the extra digits?” And it’s faster for a team member to bring up the screen than to try to explain which screen it is.
Your guideline should be to show anything that
- You want feedback on (sometimes even if the team didn't finish the item)
- Participants should see to be aware of
- That could influence the discussion throughout the rest of the review, or
- Participants ask to see.
Keeping the review focused on these items will keep the meeting shorter and faster paced. It won’t bog down in demos of things that aren’t important. This keeps your stakeholders engaged and more willing to participate in future sprint reviews.