Your quick guide to Remote Sprint Review
12 Things you Must Know About the Sprint Review
Remote Sprint Review in Scrum — Learn all you need to know with real life examples
Learn how to organize a successful Remote Sprint Review: who participates, what should be the plan, what to demonstrate to the stakeholders, how to collect feedback.
#1. What is the purpose of the Sprint Review?
The sprint review aims to get feedback from the Stakeholders on the user stories done during the sprint. The definition of user stories includes deployment to production, acceptance testing, and anything else needed to release the user story to the final user potentially.
#2. Who are the Stakeholders of the Scrum Team?
A stakeholder can be anyone interested in the functional topics covered during the demonstration of work done during the sprint. They can be managers, users, colleagues, future clients. It is up to the Product Owner to identify them and to invite them to the Sprint Review.
#3. Isn’t the Remote Sprint Review in Scrum a demo for the Product Owner?
No. The Product Owner presents the work done during the sprint review and demonstrates it to the stakeholders. While the methodology emphasizes that anyone should do the demo, I like to see the Product Owners doing it. A product owner demonstrating the work done is a Product Owner aware of what the team did, confident in the work's quality, comfortable to share it with all the participants.
#4. When does the Product Owner get his/her demo if not during the Sprint Review?
The Product Owner works together with the team to do each user story. He/she answers the questions the team has, tests, and accepts the user stories.
#5. Who attends the Remote Sprint Review?
Sprint reviews are open for everyone. Everyone is welcome to give feedback, but it is up to the product owners to consider them.
#6. What is the agenda of the Sprint Review in the Scaled Agile context?
- Review goal
- Demonstrate the work done
- Request for feedback
- Discuss work not done
- Identify risks and impediments
- Review PI objectives
- A sneak peek on the next sprint
#7. How to provide input during the Sprint Review?
Time is short, and while providing feedback, discussions can go on for a long time. I recommend using post-its to write input or use a simple Document to track feedback if you are in the same meeting room. If the users are familiar with your project management tool, they can add their product feedback directly to the product backlog.
If you are using a document online — like TFS wiki or Confluence, you can add a page there with the feedback of each Sprint Reviews, or you can create a page in One note dedicated to Sprint Reviews Feedback.
I recommend you sign the feedback so that the Product Owner can contact you for further details.
#8. Who leads the Sprint Review?
The Scrum Master facilitates the Sprint Review, and the demo is done by the Product Owner, mainly. But the team member should have the opportunity to demo as well.
#9. How long does it last the Sprint Review?
Target 1 hour. Meetings longer than 1 hour are hard to follow.
#10. What should I prepare for the sprint review?
NOTHING! As much as I love the structure and organization, I hate to do unnecessary administration work. Over the years, I became very minimalist. Try to use no presentations but the usual project management tools. Here is an overview of how it should go:
- Sprint Goal: Jira has a field to insert the sprint goal. You can find it under the sprint name. TFS has a dedicated gadget for the sprint goal.
- Demonstrate the work done — take each user story, spike, and nonfunctional requirements in the order of importance and show it directly in the production environment.
- Request for feedback. In the Sprint Review opening, the Scrum Master gives clear instructions on how to provide the input.
- Discuss work not done. Use Jira or TFS Sprint backlog as a base for the discussion. In the discussion area of each item, there should be the details discussed for a better track of each sprint backlog item's history.
- Identify risks and dependencies. I strongly recommend using Jira or TFS or any of your project management tools to log the risks and dependencies. Both Jira and TFS have a risk work item. Make sure you link it precisely to the product backlog elements that impact the same user story or feature.
- Review PI objectives. The scrum teams define the PI Objectives during the Program Increment Planning Meeting. After each Sprint Review, each team must evaluate their progress against the planned objectives. While reviewing the PI objectives, business owners will assign a business value that they think they received with the work done during the sprint. This value is subjective, and it must reflect the value that the business sees delivered during the sprint review.
- A sneak peek — open the backlog and show what the stakeholders could expect in the next sprint on high lines. In a scaled environment, the teams will have a good idea of what will come next iteration.
#11. What is NOT the Sprint Review?
- Iteration review or the sprint review is not a testing session. Testing must be part of the definition of done of each user story.
- It is not a demo done from the local environment.
- It is not a demo for the Product Owner.
- It is not a justification for hours for higher management.
#12. Tips for a Remote Sprint Review
- Introduce who is on the call,
- Break the ice with small talk,
- Share your screen and point to the place where all the participants can identify the information you are sharing,
- Decide to have only one person sharing the screen,
- Be specific in your instructions towards the participants: where people can find the team board, where they can provide feedback, where they can see the PI objectives, how you calculate specific metrics, etc. ,
- Make sure you do not have any notifications popping up on your screen. Both Mac OS and Window have a Do not disturb mode you can use,
- If you hear background noises, advise people do mute their microphone to avoid unnecessary noise,
- In the context of COVID-19, when everyone works from home, Internet connections might be unstable. Try to record the demo before and make it available in a video that all the participants can access. It will help you to bypass technical difficulties. Doing so avoids the overload of the conference tool,
- Summarise the main points of the sprint review,
- Use visual graphics to make it easier for the stakeholders to follow,
- Ask for feedback; make it interactive.
