A Kamran Sprint Review Sessions Best Practices Workshop

by A. Kamran
Lean Agile Council
Best Practices for more efficient, collaborative & productive sessions

Sprint Review Session: Best Practices
In this presentation we will take a look at:
❖Sprint Review Summary
❖Sprint Review Highlights
❖Sprint Review as per Scrum.org
❖Sprint Review Anti-Patterns
❖Sprint Review Best Practices
❖Questions?
© 2018 – 2019 A. Kamran
2

A bit about the presenter: A. Kamran
• Certified Agile Coach, Certified Scrum Master (since 2006), Certified Product Owner,
Certified Scaled Agile Enterprise Transformation Lead, Certified Scrum@Scale
Practitioner, Certified Kanban Practitioner.
• 20+ years in Project Consulting, 13+ years in Agile and Hybrid approaches.
• Consulted on, coached and/or directly managed technology solution delivery teams
for the Fortune Global 500 companies (incl. 5 major Canadian banks) as well as
Public Sector.
3
• Has launched 3 Successful Start Ups in Technology and Consulting Services; The most recent launched in
2015 using the Lean Start Up model (now a growing high tech boutique in Machine Learning technology
solutions with 4 bases of operation in:
• Toronto,
• Palo Alto (Silicon Valley, US),
• Glasgow (Scotland, UK),
• Hong Kong.
® ®

Sprint Review’s main purpose:
To get the stakeholders to see (and possibly interact) with the
completed work (as the outcome of the finished Sprint) and
collect their feedback on that, and get everyone to collaborate
on deciding what is the next best thing to do (based on current
status and what they predict the market will need) and
updating Product Backlog to reflect that.
4
© 2018 – 2019 A. Kamran

It is the Sprint End ceremony, with the main purpose of:
Inspecting and Adapting
the Product Backlog
(i.e. re-aligning the work with what market / customers want now)
5
© 2018 – 2019 A. Kamran

During Sprint Review:
Scrum Team and Stakeholders
Collaborate on review of
What was DONE (Increment)
during the Now-Complete Sprint
and …
6
© 2018 – 2019 A. Kamran

During Sprint Review:
Scrum Team and Stakeholders
Collaborate on
What needs to be DONE
in the Upcoming Sprint to
Maximize Business Value Delivered
7
© 2018 – 2019 A. Kamran

The Sprint Review includes the following elements:
1. Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
2. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
3. The Development Team discusses what went well during the Sprint, what problems it ran into, and how those
problems were solved;
4. The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
5. The Product Owner discusses the Product Backlog as it stands and projects likely target and delivery dates
based on progress to date (if needed);
6. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to
subsequent Sprint Planning;
7. Review of how the marketplace or potential use of the product might have changed what is the most valuable
thing to do next; and,
8. Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of
functionality or capability of the product.
8
© 2018 – 2019 A. Kamran

The Result of the Sprint Review:
A Revised Product Backlog
that defines the
probable Product Backlog items
for the next Sprint.
9
© 2018 – 2019 A. Kamran

The Sprint Review can suffer from a variety of Anti-Patterns:
1. Not holding any Sprint Reviews
• Sacrificing Sprint Review due to shortness of time (last minute code development or
production bug fixing which get everyone running to the release and no time to hold any
Review events before the next Sprint’s planning)
• Cancelling Sprint Review because there is Nothing to Demo (even if due to a variety of
reasons, the increment did not complete and is not ready for a Demo, there is still much
more agenda items for the Sprint Review session to be held)
10
© 2018 – 2019 A. Kamran

2. Turning Sprint Reviews into Reporting Sessions
• Moving away from the essence of collaborative review of the work and deciding on what
is the Next Best work, towards a stats of the work done (e.g. “We delivered this Sprint: 24
Stories, 8 Bug Fixes, 10 BAU work items for a total of 57 Story Points) which will not tell
your stakeholders anything about what was really DONE and delivered.
11
© 2018 – 2019 A. Kamran

3. Sleep Therapy Session
• Putting the entire session to sleep by a prolonged boring presentation of screenshots of
the increment (without any live demonstration of the work, or allowing stakeholders to
play with the completed functionalities) done by just the Scrum Master or Product Owner
as the main agenda of the Review session.
12
© 2018 – 2019 A. Kamran

4. Surprise Party
• Happens when Development team suddenly reveals during the Demo that they have
done extra – yet unwarranted – work that was not part of the Sprint Backlog and was
never discussed with the Product Owner.
This is a damaging behavior at many levels, as it would create trust issues between stakeholders and
the team, and distorts Product Owner’s relationship with the Development team, as well as injecting
work that has not been previously accepted by the Product Owner into the increment.
13
© 2018 – 2019 A. Kamran

5. Ghost “Dev” Town
• This is when we don’t have the needed Development team members attending the
Review and the Demo, which can be due to a few reasons, including:
❖Their overworked status, last minute code development or Production bug fighting.
❖They have lost faith in the value of Review sessions since historically it had not have
much outcome in the sense of collecting feedbacks and decision making on the next
best work.
14
© 2018 – 2019 A. Kamran

6. Only Works on Developer’s Machine
• This is when what is being demonstrated to the stakeholders is not really DONE
(Deployment Ready) and would only run on a Developer’s machine (since it has not been
yet integrated with the rest of the system, nor has it been tested for it and there is no
build ready for deployment).
15
© 2018 – 2019 A. Kamran

7. Missing Stakeholders
• This is when Stakeholders are not attending the Sprint Review sessions which creates a
disconnect between the Development Team and Customers (or their Reps) over the work that
is completed and the next step to be decided on. This may have a few reasons:
❖They may not be invited (Product Owners may think that them being the liaison between
Business and the Development team is good enough so why make the session crowded?)
❖They may have lost faith in productivity of the sessions due the historical disconnect
between their collaboration and the work that gets done at the end.
❖They may not have fully grasped the value of their collaboration in the Sprint Review due
to lack of familiarity with Scrum and how it works (they may work in Waterfall
environments).
❖They may be overwhelmed with work and shifting priorities in their own side and skip the
sessions as a result.
16
© 2018 – 2019 A. Kamran

8. Sprint Gating (Scrum Fall)
• This is when Stakeholders are confusing the purpose of the Sprint Review with a Project
Gating review session and instead of keeping the session in its informal setting and
participating in feedback gathering and deciding on the next best steps, they think they
are asked there to sign-off on the work that is done.
17
© 2018 – 2019 A. Kamran

9. Silent Treatment
• This is when Stakeholders are acting as spectators and refrain from sharing feedback or
participating in the joint review work and setting the next best steps for the product. The
reasons behind this behavior can be from lack of faith in the initiative to fear of backlash
if the next increment turns out to be a failure in the market.
18
© 2018 – 2019 A. Kamran

10. The All-Knowing-PO (Radio PO)
A. This is when the Product Owner believes he / she can cover the role of Stakeholders during
the review session and provide all the feedback needed on the completed Increment.
B. This also applies to when Product Owner, omnipotently decides on what needs to be built
next, without participation of Stakeholders in the conversation during the Sprint Review
sessions.
19
© 2018 – 2019 A. Kamran

20
The Sprint Review is the opportunity to Inspect and Adapt key success factors in
delivering value to the customers.
Inspect
• Sprint
• Product Backlog
• Increment
• Marketplace
• Budget
• Timeline
• Capabilities
Adapt
• Product Backlog
• Release Plan
© 2018 – 2019 A. Kamran
This is a good opportunity for the management
to see the work completed and participate in
the review activities to get an updated insight
on the alignment of the work, and what they
teams needs in order to succeed.

21
Good Sprint Review Practices
• Keep it as an informal meeting (like a meetup or expo), where the "DONE" increment is
showcased on machines where the end-users (and generally all stakeholders) can interact with
the newly completed work.
• Have refreshments for the attendees (if it runs over their lunchtime, some light lunch would be a
good idea)
• Solicit and gather feedback (over the completed work) and ideas (for the next increment).
• Let the Development Team communicate directly with end-users (or their Reps) and
stakeholders and gets direct feedback from them.
• Make sure the Product Backlog is updated after or during the Sprint Review, based on the
gathered ideas.
• Try your best to have end-users attend the session (or at least Reps closest to them).
• Keep it fun, yet focused on the purpose of the meeting.
© 2018 – 2019 A. Kamran

A Kamran Sprint Review Sessions Best Practices Workshop

Recommended

More Related Content

What's hot (19)

Similar to A Kamran Sprint Review Sessions Best Practices Workshop (20)

Recently uploaded (20)

A Kamran Sprint Review Sessions Best Practices Workshop