The Sprint Review: The Product Owners Meeting

Ashley-Christian Hardy
11 min readApr 3, 2016


“I love those who can smile in trouble, who can gather strength from distress, and grow brave by reflection. ‘Tisthe 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

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.

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 overall purpose of this meeting is to inspect the product, and the team verifies that everything that was 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. The meeting gives the opportunity for the product manager to inspect the product, and gauge if its what he wanted, 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.

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 its one of the most delicate.

Common Problems with Sprint Review

  • It’s the first time the Product Owner sees the use stories
  • Using the meeting as a demo only
  • Only user stories that are finished are demoed
  • Its only used as a meeting to see what work has been completed
  • All user stories are demoed
  • The overall project or release plan 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, or the meetings are merged.
  • Stakeholders expect work that wasn’t 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 an Effective Sprint Review


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. Its easy to get too focused on the actual demo and success of the product, and leave out the most important part. What to do next. Its not a product sign off 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 review), so 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.

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 quite structured, You can even put the agenda on the wall for everyone to see and follow. A good example for an agenda might be:

  1. Scrum master kicks off and reminds everyone of the rules
  2. 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.
  3. The team reviews the sprint and key information
  4. The team demos the user stories
  5. Product owner opens discussion with team and stakeholders to collect feedback
  6. 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.

Make sure the meeting is not missed. Its easy to understand why it might be. In my experience with teams that are starting out, the work is not kept consistent throughout the sprint or badly planned, meaning 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 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.

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, there is nothing worse than someone getting too involved that has no business to. 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.

This meeting should not be used as the only point a Product Owner sees the user stories. 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 first time the PO is seeing a user story, 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.

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, its 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; all the user 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, and there is nothing worse than stakeholders not engaged or motivated, reviewing user stories that have no or little interest for them. Keep the meeting relevant, try taking a break mid-way through to keep the focus, allow excecs to catch up with some emails.

Finally, the product owner should have full authority over the product, what is required and what needs to be done. If stakeholders are invited to the meeting that actually make the decisions (and not influence them), then the product owner role becomes redundant.

The sprint review is not an update meeting, or an opportunity to review what work is completed. A good collaborative scrum team should know the status of work completed. If not, what are you doing in your daily stand ups? I also noted in the common mistakes that the meeting is made mandatory. While its 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.

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.

If the product is going to be demoed, then it should be shown working! A general rule in sprint review is that no slides are allowed, and if they are needed; should be kept to a minimum. No sprint review should be conducted with a PowerPoint presentation of screenshots showing working software. It’s a good idea to have some focus on the acceptance criteria! The demo should also be done on the environment closest to production. If you are releasing new mobile functionality, it should be demoed on a mobile! There should also 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. It needs to be done in a testing environment, not ran of a local machine. 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.

Remember its not a Retrospectives, 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 ae two different scrum artefacts and should be managed that way. Its OK to focus on the impediments, and what went well, but remember not to focus on the how. Pin down reasons why work was not completed.

This meeting is also a good opportunity to identify any scope creep, was anything delivered that wasn’t agreed on or did requirements change mid-way through? This should be discussed and stopped for the next sprint. 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.

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.

Don’t forget to celebrate success. Although its 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
  • Its great for helping people learn and can develop some skillsets.

“Remember, the meeting is about the Product, not the people or the process.”

This post was originally posted on:
Please check my site to get the latest articles first!

About the Author

Ashley-Christian Hardy

Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.











Ashley-Christian Hardy

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.