Do you know the complete ins and outs of the Sprint Review in Scrum? This presentation goes in depth regarding this Scrum ceremony.

1. Ashley-Christian Hardy
The Sprint Review
The Product
Owners Meeting

2. Hi, I’m Ashley-Christian Hardy
In Progress…
full- stackagile.com
achardy@fullstackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm

3. “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

4. What is a Sprint Review?

5. 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.

6. Prerequisites for Effective Sprint Review
Understand the purpose of it and what benefits it brings.
Preparation is key for this meeting.
Everyone should know what the definition of 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.
The Scrum Master should 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.
Try to make the meeting fun, this can help the general environment and actually
make people want to join the meeting.

7. 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

8. Meeting Format
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.
All feedback should be welcome, and the product owner should try and get out as much as possible from the stakeholders.
This meeting should not be used as the only point a Product Owner sees the user stories.
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.
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.
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.

9. Meeting Format
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.
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.
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.

10. Meeting Format
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.
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 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.
There should also be no cheating! It defies the whole purpose of the meeting and it will
have no value.

11. Meeting Format
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 center around process improvements.
This method is about the WHAT, Retrospectives is about the HOW.
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?
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.

12. Ending 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 utilized, 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.
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.

13. Summary
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.”

14. Thank you!
Full-stackagile.com
achardy@full-stackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm
slideshare.net/ ashlychrstn
tumblr.com/ blog/achardypm
https://plus.google.com/ achardypm