Definition of Sprint Review
The sprint review, or commonly the sprint demo is a meeting that takes place at the end of the sprint, where the team showcases their “potentially shippable product”. Generally I don’t like the name “Sprint Demo”, this should not be the first and only time the product owner sees the product, or the stakeholders for that matter.
“I love those who can smile in trouble, who can gather strength from distress, and grow brave by reflection. ‘Tis the business of little minds to shrink, but they whose heart is firm, and whose conscience approves their conduct, will pursue their principles unto death.”
– Leonardo da Vinci
The aim
The aim of the sprint is to get to a point where you have a product that has been coded, tested and is usable — and can be deployed into production. The purpose of this meeting is to inspect the product, to verify that everything agreed has been accomplished.
The product owner will usually invite all relevant stakeholders to review the product, and give feedback to the team.
The common phrase heard regarding this meeting is: Inspect & Adapt. It allows the product manager to inspect the product and gauge if it’s what he wanted. To see if he is happy to release to production and how to move forward in the next iterations. The meeting should not be just a demo of the software (hence why I dislike the term Sprint Demo), the product owner takes this milestone as a chance to review the increment delivered, and how to adapt for the next sprint.
Is it just a demo?
If you review the product and simply demo it, you might think that the meeting was a success, when in actual fact you are missing the point of the meeting completely. On the outside, this seems one of the easiest meetings to do in Agile or Scrum — but in actual fact it’s one of the most delicate.
Common Problems
- It’s the first time the Product Owner sees the use stories
- Using the meeting as a demo only
- Complete stories are only reviewed
- Its only used as a meeting to see what work has been completed
- Every single story is demoed
- Overall project is not discussed
- Its made mandatory for everyone
- The team only demos to the Product Owner
- The sprint backlog is not up to date
- Scrum Master leads the meeting or has too much control
- The product owner is not the decision maker
- Becomes boring and mundane
- Confusing the review with the retrospective.
- Stakeholders expecting work that’s not planned
- Estimates are considered as committed time frames
- Used as an excuse to point the finger or blame
- Product owner does not care about the product.
- The product owner may not actually care about the product, maybe he was assigned because of his knowledge or they are a middle man for an actual stakeholder.
Tips for Effective Sprint Reviews
Prerequisites
As stated in the introduction, my first tip for running this meeting is to actually understand the purpose of it and what benefits it brings. It’s easy to get focused on the demo and leave the most important part out, what to do next. It’s not a product signoff meeting or UAT meeting. If you use it as this it can actually cause tension between the team (development team and product owner).
Preparation is key for this meeting. Part of the meeting may be demoing the product (you might be surprised to hear that not all teams actually do this as part of the sprint review). You should have a prior run through, ensure everything is set up or configured ok, the machine you are demoing on is not going to auto-install updates half way through. Saying that, you should not spend an age preparing for the meeting, 1 hour should be enough.
Everyone should know what the definition of done is!
The meeting holds little point if the team doesn’t actually know what “done” is.
Agenda
Each sprint review will be different, with different stakeholders and different decisions to make, make sure you tailor your meetings for this. Have an agenda, the meeting should be structured.
You can even put the agenda on the wall for everyone to see and follow. A good example for an agenda might be:
- Scrum master kicks off and reminds everyone of the rules
- The PO presents the sprint goal and what he wanted out of the sprint and why, including the progress of the project and the big picture.
- The team reviews the sprint and key information
- The team demos the user stories
- Product owner opens discussion with team and stakeholders to collect feedback
- Product owner closes with a short summary and a high level plan on what to do next.
A good idea also is for the Scrum Master to send out material before the meeting, information on the sprint, how it went and some facts and figures to that everyone is on the same page. The meeting requires a good facilitator, and the Scrum Master needs to ensure the meeting stays on track and resolves any conflicts.
Don’t miss it
The meeting should not be missed and it’s easy to understand why sometimes it could.
In my experience with teams that are new, work is not kept consistent throughout the sprint or badly planned. This means that there is a rush or pressure at the end of the sprint, meaning the team may not have time or see the meeting as a waste of it. Try to make the meeting fun, this can help the general environment and actually make people want to join the meeting. Bring drinks and snacks, include activities or participation. This will make people feel more relaxed and could prize out some of that critical feedback.
Meeting Format
The meeting should be informal. Its not a reporting exercise. It’s the opportunity to get and give feedback, and a comfortable atmosphere will better facilitate this.
As with all meetings in Scrum, it’s a time-boxed meeting — for the sprint review it should be:
- One week sprint = 1 hour
- Two week sprint = 2 hours
- Four week sprint = 4 hours
The meeting should be ‘led’ by the Product Owner, out of the meeting the Product Owner should have a more refined product backlog and an updated release plan. It’s a good idea for the PO to actually introduce the meeting by reviewing what the sprint/release goal was and an overview of what requirements were needed. Although the Scrum Master can facilitate the meeting, he should not have any input. He is there to ensure that the rules and practices of Scrum are adhered to.
Feedback
All feedback should be welcome, and the product owner should try and get out as much as possible from the stakeholders. You must ensure though that the right stakeholders are there, so the meeting is not disruptive. There should be lots of feedback and ideas on how to move forward, this is the Product Owners chance to add them to his product backlog.
The product owner should not be seeing stories for the first time here. Remember, Agile is about collaboration, and the PO should be working with the development team to clarify and work on the product. If this is the case then much more is broken than your Sprint Review.
It also reduces risk and any in-clarity or problems are found early on. By not doing this, you can also run the risk of the Product Owner not knowing what to expect from the user stories, and if he has invited all of his stakeholders, there is a high probability the meeting will not go so well. The PO and the team can actually prepare how the demo will go before.
What to review
As pointed out in my initial list of issues, the team should not only demo fully working or complete user stories, the aim is to get feedback — I think demoing should actually be at the discretion of the Product Owner. If he feels demoing something will have value and help determine the next actions, it’s should be discussed. If not, then don’t waste time. I think this also goes hand in hand with another mistake I pointed out earlier that all stories are demoed. There should be some kind of filter applied to the meeting (by the PO) on what to demo, and it should have some dependence on what stakeholders are there.
The meeting should be engaging and valuable. There is nothing worse than stakeholders not engaged by reviewing stories that have no interest for them. Keep the meeting relevant, try taking a break mid-way through to keep the focus, allow executives to catch up with some emails.
Product owners role
The product owner should have full authority over the product.
If stakeholders are invited to the meeting that actually make the decisions (and not influence them), then the product owner role becomes redundant.
A good collaborative scrum team should know the status of work completed, meaning this should not be an update meeting. If not, what are you doing in your daily stand ups?
The meeting needs to be mandatory. While it’s great that the whole team and stakeholders attend, I have found in reality its difficult to get everyone together. Not only this, but stakeholders should act as a team, not individuals with their own interests.
Impact of postponing
Such constraints as meeting rooms (size and availability), peoples schedules or a number of other issues that may impact the meeting, and the first instinct is always to postpone. I generally don’t like this approach, because once you postpone once and get out of routine, it can be hard to get the meeting back up. If you can conduct the meeting with the minimum needed people, then do it anyway. You can always update the people who could not attend.
When the increment is demoed it should be shown working.
There should be no slides in the sprint review, if they are then they should be a minimum needed. No demo should consist of a PowerPoint presentation of screenshots showing working software. It’s a good idea to have some focus on the acceptance criteria and the demo should be done on an environment closest to production. If you are releasing new mobile functionality, it should be demoed on a mobile.
There should be no cheating. It defies the whole purpose of the meeting and it will have no value. No rigged or hard-coded software that gives the appearance of working functionality. If it doesn’t work, it needs to be investigated so the team can properly adapt.
Remember its important to show useful and valuable software, and also provide the context, you can even role play as the user! This is great for use involvement, think of scenarios and fully test the user story.
Its not a retrospective
Remember it’s not a retrospective, so discussion should not start to centre around process improvements. This method is about the WHAT, Retrospectives is about the HOW. These meetings often are blended together which in my opinion is wrong. They are two different scrum ceremonies. It’s OK to focus on the impediments, and what went well, but remember not to focus on the how.
This meeting is also a good opportunity to identify any scope creep. Was anything delivered that wasn’t agreed or did requirements change? This should be addressed and prevented. Any work incomplete should return back to the product backlog. The team should have some brief time to refine the product backlog, so that the sprint planning can occur smoothly.
Environment
My last point is regarding the environment; the atmosphere is very important. There should be an environment of trust. The team should have the confidence to say when things are not finished. Teams might see this as a failure and it could reduce moral and leave them feeling exposed. This should not be the case as you will quickly find that your products quality will reduce and the technical debt will increase.
Ending the Meeting
As mentioned, by the end of the meeting I think its super important that the overall project is discussed, and what to do next. The remaining backlog should be reviewed and discussed, what’s missing and what needs to be adapted. Some teams use their burn down or burn up charts, or whatever project status recording method utilised, its good practice and allows the Product Owner to make more informed decisions on what to do next. Review the product backlog and even let the stakeholders give their insights. What to do next can actually be a short discussion at the end of the meeting. The Product Owner can present his initial idea based on the feedback he has just received from the meeting.
Celebrate
Don’t forget to celebrate success. Although it’s not a meeting where recognition is mandatory, it should be an opportunity for the team to celebrate success or failure to keep moral high.
A good point to remember is that you will be in the room with many stakeholders, some of which will be important people in the company and key decision makers. Be sure to tell these people about your impediments if you have any, but be careful. The job of removing impediments is that of the Scrum Master, remember there is a time and a place.
Try to also measure the meeting. Get some feedback or general consensus on how the meeting went. Look to how it can be improved for next time. You should not just be inspecting and adapting the product, but the process as well.
In summary, the clear benefits for a good Sprint Review are:
- The stakeholders are engaged and feedback is more likely to be valuable
- It’s a great team building exercise if done right, and can improve culture.
- It puts the focus on quality
- It’s great for helping people learn and can develop some skillsets.
“Remember, the meeting is about the Product, not the people or the process.”
Social Media
Please check me out on social media:
