It’s pretty well known that development teams don’t like to waste time in unproductive meetings. However, Sprint Reviews are one meeting your team shouldn’t skip - they’re a part of Scrum for a reason! When run correctly, Sprint Reviews will level up your team and make your next Sprint that much better. If your Sprint Reviews are feeling stale, or you aren't holding them, we have some tips for how to improve.
Sprint Reviews 101
So, what is a Sprint Review? In short, it’s a way for the following people to get together for a demo, or show-and-tell, at the end of a Sprint:
- Product Owner
- Scrum Master
- Any other stakeholders (including management and even the end-users)
Scrum calls for the completion of a shippable product increment during each sprint. Therefore, you should be able to demonstrate a fully-functional feature, or set of features, at the end of each Sprint. So, think of this meeting as a celebration of that accomplishment.
The purpose and goal of a Sprint Review
The purpose of this meeting is to answer a simple question:
Did the team meet the goal assigned at the beginning of the sprint?
To be clear, even if the answer is a resounding no, the Sprint Review should still recognize the team for the work that was completed. Everyone should actively participate in the Sprint Review by offering questions, comments, or concerns (nicely!) on the work done.
Often times this meeting will help shape future sprints. For example, based on what the developers show, the team may need to make changes to the product backlog before the next sprint. Whether this happens is based on criteria like:
- Whether the team met the initial goals set during the sprint planning meeting
- What insights are provided by those present during the Sprint Review
If your Sprint Reviews are starting to feel stale one reason might be you’ve slipped into only focusing on showing completed work. Don’t forget to make these meetings interactive so that each member of the team can offer their perspective on the completed work. This is a great opportunity for an open discussion.
Holding an effective Sprint Review
Now that we’ve established the purpose of a Sprint Review, how should you run yours? How do you ensure your team gets the most value out of their time? How do you foster a collaborative environment where people feel free to share their thoughts without fear? Read on for some of our favorite tips on how to structure and run your Sprint Reviews.
Keep it short and stay the course
A great question to ask the team is: How short can you make your Sprint Review without sacrificing quality?
Many teams keep Sprint Reviews to no more than two hours for a two-week Sprint, but can yours be even shorter? Some groups have reduced the amount of time spent on Sprint Reviews from two hours to an hour.
Limit what is covered in these meetings to keep it short. Remember, a Sprint Review isn’t the same thing as a Sprint Retrospective. The Sprint Review is a time to celebrate the progress your team has made. Save the conversation about what they should or should not be doing for the Sprint Retrospective. By keeping the two separate, you’ll save time and preserve the effectiveness of both aspects of the Scrum process.
If you still find yourself sitting in Sprint Reviews (or any other meetings for that matter) that are way too long, consider timeboxing. Timeboxing is the process of scheduling out exactly how much time should be spent on each task (e.g., 5 minutes for introductions, 10 minutes for a demo of the first item, etc.). Obviously, you’ll need to nominate someone on the team to enforce such limits during the meeting.
Set an agenda
Sprint reviews are informal, but they needn’t be anarchy. So what do you do?
Setting an agenda, however loose, will help set your team’s expectations and keep you on track For example, you might stick to a simple four-part Sprint Review:
- Review the results of the sprint: the product owner covers which items of the backlog were completed during the sprint (as well as any that weren’t and why)
- Demonstrate the work: the dev team demos their work and talks about the successes and challenges encountered during the sprint
- Gather feedback: during and after the demo, the entire Scrum team should feel free to offer feedback about the completed work. The product owner should ensure this information is well documented.
- Update the project and plan for future work: based on the demo and the feedback received, the product owner should lead the group in updating the backlog to reflect changes in scope, newly discovered work, shifts in priorities, and unfinished pieces of work in order to prepare for future sprints.
There is no one size fits all for Sprint Reviews. Your team will have to decide what works best for them. Only by trial-and-error can you determine the right about of structure for your team.
Consider an alternate format
The typical show-and-tell format has the advantage of being simple and recognizable. However, changing your meeting format can bring new energy into your Sprint Reviews.
For example, you might consider a bazaar-style Sprint Review. This is a very hands-on format where the stakeholders get a chance to try out new features one at a time and offer feedback in a structured, yet informal way. There are no presentations, just the opportunity to try out the brand new features.
There's a fine line between constructive feedback and critical judgment. It’s crucial that the Sprint Review maintains a positive spirit. The team shouldn’t feel as if the Sprint Review is an opportunity for the product owner and other stakeholders to “grade” or judge the work they have completed.
One way to prevent this is to include the product owner as an active participant during the demo. How does this help? Well, when the person who set the direction of the feature work actively participates they become “one of us” instead of “one of them.” There’s likely to be a trickle-down effect where everyone works together and when something needs to be addressed, it’s likely to be done in a collaborative, fair, and useful manner.
Sprint reviews are a vital component of the Scrum process, but they can easily become stale and less effective.
Don’t let this happen -- with the tips provided above, you can make sure that your team’s Sprint Reviews stay productive and effective. Sprint reviews are a great way to gather feedback informally, but more importantly, it’s a bi-weekly celebration of what your team has accomplished. What could be better?
Is your Scrum team struggling to manage your GitHub issues? Let ZenHub help you streamline your development process today!