I’m passionate about understanding what makes software engineering teams great, and applying and sharing that understanding however I can. And of the many different ways I’ve seen software built over the years, I’m convinced that Agile and Scrum – if they are applied well – combine to form a highly successful approach to building software. To that end, I have several posts about different aspects of Agile and Scrum, based on my own experience over the years. Here’s one of them.
Scrum.org says, “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.” In my experience, this is the method that has worked most effectively:
- Review what was accomplished during the Sprint in priority order, for two reasons. First, good meeting discipline is essential to healthy teams. So get to the important stuff first. If you end up spending all of the allotted time on the first item, then so be it. And second, this reinforces the team’s understanding of the priorities. If the team demonstrates Item A, but the stakeholders are more interested in Item B, then that’s a discussion to be had. And if everyone understands that the Sprint Review is in priority order, then the moment the team brings up Item A is when the stakeholders should recognize the problem.
Shortly after the Sprint Review, the team should be entering into Sprint Planning for the next Sprint. And what happens in the former informs what happens in the latter. If you don’t get to the important items in time, then you’re flying blind in Sprint Planning. And if you’re running over in Sprint Review, then you’re likely impacting the schedule for Sprint Planning. In both cases, you’re messing up the next Sprint before it can even get started.
I’ve been a part of plenty of teams for which “everything’s a priority.” And it never works. Being able to properly stack-rank a team’s work is essential. And the Sprint Review is the best place to fix this. You have all the necessary people in the same room together. If you have a prioritization issue, then take this time and fix it. You can ask nicely: “What would you like to see first?” is both subtle and effective. But hold the stakeholders hostage in the meeting if you must.
- Have the tester/reviewer for each work item present it. Maybe you have dedicated QA and testing staff, or rely on peer reviews and oversight by other developers, or some a mix of the two, or maybe some other solution altogether. Whatever the make-up of your quality control, have the people who fill this role be the ones who present it.
I’ve found this advice to be quite controversial. But I have also found that it raises the team’s effectiveness considerably. Team members learn more from each other. Code quality goes up. The bus factor goes up. Even the simple fact that it calls out that every work item should have someone in that role is a benefit. It’s too easy for teams to slip into bad habits like rubber-stamp PR reviews, and this attacks those bad habits directly.
As the developer in this scenario, I’ve found that one way this practice improves the quality of my work comes from my desire to not embarrass the presenter. It’s one thing for me to shrug off an issue during a demo. It’s another matter entirely to watch someone else look bad in front of everyone due to my mistake. And it also raises my game as the reviewer. If I have to present someone else’s work to stakeholders, I’m going to make sure I thoroughly understand it and have thoroughly vetted it.
- Accept feedback but do not make decisions yet. The only decisions that should come out of the Sprint Review are changes in prioritization. The rest is information-gathering for topics to be discussed later (probably in Backlog Refinement meetings).
The stakeholders in a Sprint Review frequently outrank the presenters. In those situations, it’s too easy to “give in” to whatever demands they might make. But such demands should be given careful consideration, and the Sprint Review is not the time and place for that.
I’ve been in situations in which a Sprint Review was a massive eye-opener. What the team presented was not what stakeholders were expecting. It is very easy to get off the rails in these meetings, especially when those same stakeholders begin to panic over direction, resources, and timelines. As with so many issues, the key is prioritization. What needs to happen next? How that happens is a discussion to be had later. It’s very easy in these meetings to focus on how, and not what or why. Be clear about the what and why, and get the question of how off the table.
And that’s all there is to a good Sprint Review. Remember, with a large and diverse group of participants, it’s important to stay focused on just the essential elements – show the stakeholders what has been done, in priority order, solicit feedback, and then settle on any changes to those priorities.