Sprint Review Meeting |sprint riˈvyo͞o ˈmētiNG|
- the assembly of the Scrum Team, at the end of every sprint, where the Developers demonstrate completed work to the Product Owner for acceptance. Usage: Let’s not be late for the Sprint Review Meeting.
Based on the above definition for the Sprint Review meeting, one might imagine these are dull and lifeless events, full of techno-babble, acronyms, and the examination of code.
In reality they don’t have to be. After all, the backlog items represent “business value” so the demonstrations can focus on that. No matter the nature of the completed work, whether it’s a webpage, or application user interface or backend business logic, it can be demonstrated in a compelling way.
The key is to think about telling a story, which includes setting the context, describing the challenge and revealing the outcome. Considering that anyone in the organization could attend the Sprint Review Meeting, this is an opportunity for the Developers to impress the audience with their technical skills and showmanship.
Before the Sprint Review Meeting
- Plan the Demonstration – Before the Sprint Review meeting, the Developers should decide who will demonstrate what and when. Also the team should identify and obtain any special hardware, tools, access or configuration necessary to facilitate showing their work.
During the Sprint Review Meeting
- Identify the Backlog Item(s) to be Demonstrated – At the Sprint Review, start by identifying which backlog item is about to be demonstrated. The Product Owner is probably very familiar with each of them but by calling them out explicitly (e.g. ID#, title, or user story), it will help prepare him to evaluate the work. Sometimes it makes sense to demonstrate more than one backlog item at the same time. In these cases, it should be made clear that multiple items will be covered.
- Summarize the Backlog Item – Briefly describe what the backlog item was asking for so any attendees who aren’t regularly tracking sprint work can understand what they’re about to see. The description may not be necessary for the Product Owner but he will appreciate knowing that the Developers understood what he was looking for.
- Set the Stage – The best way to illustrate completed work is to show what existed before. For example, if a user interface was modified, show the old version first; if the backlog item calls for new files to be created, show that they didn’t exist before. Focus on this aspect just long enough to establish the starting point and give the audience a sense of what will be changing.
- Describe the Implementation – Briefly describe how the backlog item was implemented as a lead-in to showing the results. Hold back on the details unless specifically asked or the Sprint Review meeting will lose focus and may not finish within the time allotted.
- Show the End Result – Demonstrate what was created for the backlog item, pointing out those aspects that specifically meet the acceptance criteria. If the Developers cannot figure out how to best demonstrate the work, ask the Product Owner before the meeting as he may want to see something specific to be satisfied.
- Solicit Questions – Open the floor up for questions but make sure the Product Owner has the opportunity to ask if he has any. Be mindful not to lose track of why everyone is there and table any unnecessary technical discussions until a later time.
- Obtain a Definitive Answer – Lastly, if the Product Owner doesn’t explicitly state it, ask if he accepts the work. If the acceptance isn’t definitive or he outright rejects it, ask what he thought was missing so the team can figure out where the disconnect was.
Example Demonstration Dialog (with corresponding guidelines in [square brackets])
“ Hello everyone, I’m going to demonstrate item #B-042,  which gives the website user the ability to have the username remembered for up to two weeks.  Here’s what the login page looked like beforehand, notice there’s no option for having the site remember the username.  To achieve this, we used cookies with a short script and worked with the graphics design guys to make it look nice.  Here’s what it looks like implemented and we can step through enabling and disabling the feature.  Well, that’s it; are there any questions?  Does the Product Owner accept the work?”
Based on the above example, all the guidelines don’t have to result in a long winded presentation for each backlog item. The key is to cover the essential elements that make for telling a good story.
Developers should remember that while the purpose of the Sprint Review meeting is to demonstrate completed work, it represents a great opportunity to impress others with their skills. The best Developers are those who can deliver solutions and interface well with the business side of the organization.
© 2012 William Patrick Swisher