A lightning talk I gave at the South African Scrum Gathering on 14 Sep 2011 (#SGZA) in Cape Town. It examines why sprint reviews are so often awful and how we need to follow some of the rules of a retrospective if we are to achieve value from the review process

1. Your Sprint Review
Carlo Kruger S
(@ironicbuddha)
UX
Leaders in facilitating lasting Agile change
1

2. 2
This story has had its serial numbers filed off to protect the innocent (and in case anyone in
the audeience from that team recognises it)
Very short Review,
Developers didn’t know the system too well, and besides hated public speaking
so threw tester under the bus and tester did all demoes,
dev’s facing to finish by review time, frequently broke things by checkins just before review.
Team didn’t want to do reviews anymore
managers from the business side used the session to complain about things PO didn’t
prioritise
Never comment on work in the sprint
Stakeholders felt stories too small and boring, why did it take so long to develop
Team demoralized

3. 3
Team has an awesome ScrumMaster, so made it the topic of
the retrospective
Team we wanted to address:
1 - show value in what the team has worked on
2 - include the entire team in the process
3 - show the benefits of doing Scrum (important as like many
teams, still building credibility for Agile in the organisation )
Retrospective Actions:
Review now had a structure and agenda
explain the value of the stories
Added context of sprint in the overall release plan

4. 4
Result? Applause!
Happy team and PO, felt their hard work had been recognised
Energised for the next sprint

5. Well,
that went well,
right?
5

6. No Applause, please!
6
Ken wrote an article (sadly no longer available on SA site called “No Applause Please”
As humans we crave applause and unconsciously will do whatever we can to get it
So what are the chances we will expose failure in a meeting where we crave approval and
applause?

7. 7
Misunderstood role of the Review.
It is not intended as stakeholder communication or
management
Supposed to be an inspect & adapt point for the Product!

8. 8
Failure
As adults we only learn through trying and learning from the
outcome
Without safety we will not expose failure, ergo we never learn

9. 9
Lowering the stakes & create Safety to allow
failure back in the room
- remove managers
- focus on the team and contributors (who
came to SP1)

10. Whose work are we
inspecting?
10
The team’s work is done. If they meet their DOD, there is no
need to look further
We’re actually inspecting the PO’s work. We are collaborating
on “what should the product do next”
The PO chooses to accept the PO’s work (or not)

11. a facilitated
conversation
resulting in action
11
Can the PO facilitate his own review?

12. how can reviews
be more
like retrospectives?
12

13. Scrum
to God
honest 20 th
Century
Schwaberian
#HTGTCSS
13

14. 14
The dirty secret of Scrum is that we did not (yet) have a
retrospective in the original version of Scrum

15. Set the Stage
15
What was the sprint goal?
How many stories did we commit to?
How did we do?

16. Gather
Data
16
Look at the software produced
Everyone should have a chance to USE the software

17. Generate
Insights
17
Analyse the fit for purpose, direction, progress
Does the vision still fit?
Does our next sprint align with the insights we’re
generating?

18. Choose Focus
18
Set Sprint Goal
What are we going to change about our product?
(functionality, priority)
How will we measure the impact of those changes?

19. Close the Review
19
Review the outcome of the review
identify new stories
identify new priorities

20. 20
20m at table
3 min presentation per table

21. @ironicbuddha
www.scrumsense.com
Leaders in facilitating lasting Agile change
21