The Sprint Review
The most obvious activity in a Sprint Review Meeting is the demonstration of functionality built in the previous Sprint. However, a good Sprint Review is more than just a demonstration. Let's look together at an agenda for a review meeting.
Creating the right setting for the review
The product owner starts the sprint review meeting by welcoming all participants. It is quite enough if he says something like, "Thank you all for being here."
If those present do not know each other, the product owner can ask them to briefly introduce themselves. At the beginning of a new product development initiative, a round of introductions is generally a good idea. The product owner may know that Joe from Marketing is Joe from Marketing; however, the team members may not.
It's also a good idea for all participants to briefly introduce themselves when new participants occasionally join the Sprint Reviews. After all, Joe from Marketing may only come to the Sprint Reviews of the two Sprints in which the team worked on marketing-related features.
Introductions should be really brief and to the point. "Hi, I'm Mike and I'm a developer. I worked on the shopping cart features," is almost too much. "Hi, I'm Mike and I'm a developer," would be enough in most cases. However, once a team reaches a certain size, it can be quite helpful for stakeholders to briefly hear about what each individual has been working on.
After the welcome and any introductions needed at the beginning, the product owner can set some more rules or announce the expectations for the sprint review. For example, some Product Owners find it important to point out to always remain friendly during the Sprint Review. So if someone doesn't like the way a feature was implemented, they are of course welcome to say so; however, they should not call the implementation "stupid." Yes, of course we all know such things anyway, but sometimes it needs to be reminded again.
Depending on the number of participants and many other factors, the product owner can also explain to those present that while the review is looking for feedback on the features built so far, this is not the time and place to completely redesign features.
Once you're done with the intro and rules for the review, it's time to move on to the next item on the agenda.
What will be demonstrated in a review - and what not?
At this point, many teams start directly with the demonstration. I recommend that the product owner first gives a brief overview of what is to be demonstrated and what is not.
To avoid the product owner just reading out a list of items that the participants can't follow, this should be shown on a monitor or projector for all to see. Or print out the list in advance for those who might want a copy.
Personally, I like to send this information as a Word document in an email to all potential Sprint Review Meeting participants the night before the meeting. This gives people a chance to see in advance what will be demonstrated. Based on that, everyone can then decide for themselves if it is worth it for him/her to attend the Sprint Review.
The following table shows the information that I think is relevant for each Product Backlog Item. I would suggest listing the items in the order in which they are demonstrated. However, this can be changed on the fly as needed.
The first item in the table is a description of the respective item. A user story or other description is inserted there. Next comes the size of the items - usually in story points. After that comes the status of the items. Mainly it's whether they are completed or not. But anything else that seems important in that regard can be added there as well. The last column indicates whether the item will be demonstrated or not.
You may wonder why there should be items on the list at all that will not be demonstrated. I have included some examples in the table above. Quite obviously, the item that was included in the sprint but then dropped cannot be demonstrated. I've also listed a bug fix that only involves an update to a character on a screen - this item is also not intended to be demonstrated.
It is quite possible that one or more of the participants will ask for an item that was not actually intended for the demo. If that happens, feel free to present that item along with the other items. The point is not to avoid showing certain items, but to be respectful of people's time by not showing them items that you don't need feedback on.
In the example table, I listed a Product Backlog item that was added during the Sprint. I think it's useful to be able to see which items were scheduled for the sprint from the beginning and which were added during the sprint. If it is more common for items to be added during the sprint, you can think about adding a column to the table and noting there whether the items were planned or added after the fact.
In addition, you can also add a column to the far right indicating whether the items were accepted by the review meeting participants, are ready for release, or similar. This is especially useful if these decisions are an official part of the Sprint Review.
Try not to spend too much time on this part of the agenda. The goal here is not to get feedback on items or talk about why a planned item was only partially implemented. This list is simply to present the content of the meeting. After the product owner has presented this list, we move on to the main part of the sprint review: the demonstration.
New Functionalities
This is the heart of any Sprint Review meeting. If you are already doing Sprint Reviews it is also quite possible that this is the only part of the agenda that you actually do.
In this part of the Sprint Review, you go through the list of items one by one that you have previously shown to the attendees. Please remember that the purpose of a Sprint Review meeting is to get feedback.
There is no set rule as to who should do the demo. In some cases, the product owner will do it. I would always suggest that when particularly difficult stakeholders are participating in the review. In other cases, the respective team members will demonstrate the items they worked on themselves. Almost any variation is allowed here. Just experiment with it a bit and find out what works best for your team.
The most important Items
This is the heart of any Sprint Review meeting. If you are already doing Sprint Reviews it is also quite possible that this is the only part of the agenda that you actually do.
In this part of the Sprint Review, you go through the list of items one by one that you have previously shown to the attendees. Please remember that the purpose of a Sprint Review meeting is to get feedback.
There is no set rule as to who should do the demo. In some cases, the product owner will do it. I would always suggest that when particularly difficult stakeholders are participating in the review. In other cases, the respective team members will demonstrate the items they worked on themselves. Almost any variation is allowed here. Just experiment with it a bit and find out what works best for your team.
The upcoming product backlog items
The last item on the Sprint Review agenda should be a discussion of the next work in the Product Backlog. Since the purpose of the Sprint Review is to get feedback on the work from the current Sprint, it often influences the work of the following Sprints.
For example, if the stakeholders really like the look of the new screens, the product owner may want to quickly adapt other areas of the product to the new design. Or, the stakeholder may not like the way the features were implemented. Then the next sprint can be used to fix these issues instead of moving on to the next items (as would have happened without a sprint review).
The product owner starts the discussion by presenting the next potential items from the product backlog. He might then say something like, "On the screen you see ten items that I had planned for the next sprint. However, I would still like to add item XY, which came up today. I'll probably slip it in there as item #3."
The product owner then asks the participants for their opinion on this list. However, in my opinion, the Product Owner should not prioritize during the Sprint Review based on these comments. There are several reasons for this. The Product Owner may need some time to think about what was said. Or maybe the product owner wants to get assessments from the team on the changes that were requested in the review, etc. So the product owner gets opinions in the sprint review and makes the final decisions calmly after the meeting.
The end of each Review
Simply end the meeting by thanking everyone for their participation. Also, consider thanking the team as a whole for their work in the last sprint, or occasionally one or two team members who performed particularly well. Then remind everyone when and where the next Sprint Review Meeting will be held.
After the Sprint Review
Even if it is not directly part of the Sprint Review agenda, it should be ensured that all new Product Backlog items are also transferred to the team's tool or written on a Post-It and attached to the Scrum Board.