WARNING: On the surface, this Scrum activity appears to be both simple and straightforward. But be warned: without careful preparation, this session can lead to riotous table-thumping and streams of tears.
Just show the stakeholders what was completed over the sprint (past 2 weeks) — sounds simple right? Well, based on my experience, a sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate.
The core issue is aligning the expectations of a disparate group of stakeholders. These people are often more senior in the business relative to the team, they most certainly have less familiarity with the project compared to the team.
Scene Setting
Before you show any output during demo please explain why we are doing this. I am not saying you have to start from the beginning from envisioning phase of the product but definitely try explaining where you were left last sprint and what you are planning to achieve this sprint. Also it doesn’t hurt to explain the definition of done. This should help to set the stage.
Here is great video which explains why often "why" (http://goo.gl/yjmdNO) is so important
The Main Event - Sprint Review
To ensure the main event goes smoothly here are few recommended steps which you may consider to take to provide better experience for everyone.
Remember preparation is the key for the sprint review meeting and that should happen prior to the sprint review meeting. Identify user stories you are planning to demonstrate before the sprint review.
1. Prepare a demo workflow script
2. Prepare some basic demo data.
3. Ensure the demo environment is working as expected. We don't want to be stuck during demo.
You don’t want the team to spend too much time on these tasks, as the sprint review shouldn’t be turned into a dog-and-pony show, but these tasks certainly need to be acknowledged. There are also a few important points to stress to the team during sprint planning.
Instead of a one-way showcase, the demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team. It should be an open and honest discussion focusing on what was completed and what is coming up next.
Remember that this session should not become a smoke-and-mirrors slide show presentation to impress the attending stakeholders. I assure you that misleading demonstrations will only come back to bite everyone.
Preview at the Review
It is a fundamental tenet that during the sprint review, the team should demonstrate only stories that meet the definition of done. It makes sense, but it can be very frustrating for some stakeholders, and the reality is that the team will possibly receive pressure to still show what has been worked on (even if it is not quite finished).
In this situation, instead of being a stubborn mule, I recommend creating an additional agenda item labeled “Coming Soon.” This way, much like a movie preview, there is acknowledgment that the work isn’t complete, yet the stakeholders still get a sense of work that’s on the boiler and is coming soon to a sprint review near you!
Impediments
Following the show, it can also be a good idea to discuss any impediments that impacted the sprint, including why they occurred and how they were dealt with. This is an opportunity to lobby for greater assistance if there are any systemic impediments. An example might be the physical environment—perhaps a problem dealing with the facilities department in your mission to get larger desks or more breakout space.
In addition, I recommend using this segment to briefly make a point of key process improvements that were implemented to help achieve the sprint goal. Don’t go into detail here, as this session is about reviewing the product, but a quick mention won’t hurt and is a great opportunity to demonstrate to the stakeholders that the team is constantly improving.
So-Called Suggestions
There will no doubt be a range of questions and suggestions that surface throughout the session. I recommend that questions be controlled and kept on topic. The team should answer any and all questions that surface in relation to what is being demonstrated; however, questions that are tangential or completely off topic should be taken “offline” in a separate meeting.
Acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down somewhere. Any valuable suggestions which is related to the product should of course be added for further discussions under "Discussions" list and in future you may consider to discuss the item with Product Owner and after approval move it to "Product Backlog".
Picnics or Battles
Sprint reviews can be akin to turning up for a picnic or, alternatively, turning up for pitched battle! It comes down to taking the necessary precautions and treating each session seriously while still having some fun. Don’t assume that everyone has the same level of background as the team, and ensure that all attendees are made to feel comfortable by always explaining what is happening and why.
Aligning everyone’s expectations is the name of the game, and achieving this objective is critical if you prefer picnics to battles!
Just show the stakeholders what was completed over the sprint (past 2 weeks) — sounds simple right? Well, based on my experience, a sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate.
The core issue is aligning the expectations of a disparate group of stakeholders. These people are often more senior in the business relative to the team, they most certainly have less familiarity with the project compared to the team.
Scene Setting
Before you show any output during demo please explain why we are doing this. I am not saying you have to start from the beginning from envisioning phase of the product but definitely try explaining where you were left last sprint and what you are planning to achieve this sprint. Also it doesn’t hurt to explain the definition of done. This should help to set the stage.
Here is great video which explains why often "why" (http://goo.gl/yjmdNO) is so important
The Main Event - Sprint Review
To ensure the main event goes smoothly here are few recommended steps which you may consider to take to provide better experience for everyone.
Remember preparation is the key for the sprint review meeting and that should happen prior to the sprint review meeting. Identify user stories you are planning to demonstrate before the sprint review.
1. Prepare a demo workflow script
2. Prepare some basic demo data.
3. Ensure the demo environment is working as expected. We don't want to be stuck during demo.
You don’t want the team to spend too much time on these tasks, as the sprint review shouldn’t be turned into a dog-and-pony show, but these tasks certainly need to be acknowledged. There are also a few important points to stress to the team during sprint planning.
Instead of a one-way showcase, the demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team. It should be an open and honest discussion focusing on what was completed and what is coming up next.
Remember that this session should not become a smoke-and-mirrors slide show presentation to impress the attending stakeholders. I assure you that misleading demonstrations will only come back to bite everyone.
Preview at the Review
It is a fundamental tenet that during the sprint review, the team should demonstrate only stories that meet the definition of done. It makes sense, but it can be very frustrating for some stakeholders, and the reality is that the team will possibly receive pressure to still show what has been worked on (even if it is not quite finished).
In this situation, instead of being a stubborn mule, I recommend creating an additional agenda item labeled “Coming Soon.” This way, much like a movie preview, there is acknowledgment that the work isn’t complete, yet the stakeholders still get a sense of work that’s on the boiler and is coming soon to a sprint review near you!
Impediments
Following the show, it can also be a good idea to discuss any impediments that impacted the sprint, including why they occurred and how they were dealt with. This is an opportunity to lobby for greater assistance if there are any systemic impediments. An example might be the physical environment—perhaps a problem dealing with the facilities department in your mission to get larger desks or more breakout space.
In addition, I recommend using this segment to briefly make a point of key process improvements that were implemented to help achieve the sprint goal. Don’t go into detail here, as this session is about reviewing the product, but a quick mention won’t hurt and is a great opportunity to demonstrate to the stakeholders that the team is constantly improving.
So-Called Suggestions
There will no doubt be a range of questions and suggestions that surface throughout the session. I recommend that questions be controlled and kept on topic. The team should answer any and all questions that surface in relation to what is being demonstrated; however, questions that are tangential or completely off topic should be taken “offline” in a separate meeting.
Acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down somewhere. Any valuable suggestions which is related to the product should of course be added for further discussions under "Discussions" list and in future you may consider to discuss the item with Product Owner and after approval move it to "Product Backlog".
Picnics or Battles
Sprint reviews can be akin to turning up for a picnic or, alternatively, turning up for pitched battle! It comes down to taking the necessary precautions and treating each session seriously while still having some fun. Don’t assume that everyone has the same level of background as the team, and ensure that all attendees are made to feel comfortable by always explaining what is happening and why.
Aligning everyone’s expectations is the name of the game, and achieving this objective is critical if you prefer picnics to battles!
