- We're dissecting Scrum
to take a look at it piece by piece.
Today it's the turn of the Sprint Review.
TLDR, it's more than just a demo.
Hi my name is Gary Strum,
welcome to Development That Pays,
we do a video like this one
every Wednesday or sometimes every other Wednesday.
If you like what you see please consider subscribing
and hit that Bell icon so you don't miss a thing.
Empirical process control,
otherwise known as empiricism.
Is that ringing any bells?
It might surprise you to know that empiricism
is the thing on which Scrum is founded.
It says so right there in the Scrum guide,
unluckily for us it contains a definition as well.
Empiricism asserts that knowledge comes from experience
and from making decisions based on what is known.
The Scrum guide goes on to talk about
the three pillars of empirical process control.
Transparency, inspection and adaptation,
and the Sprint Review is all about those last two pillars,
at the end of each Sprint we inspect and we adapt,
but what do we inspect and what gets adapted?
Well slightly simplistically it's the increment
that is inspected and it is the product backlog
that is adapted, and this is probably a good point
to say that the picture you're looking at now forms
the center point of a rather lovely cheat sheet.
The Scrum cheat sheet.
A copy of which is waiting for you at the other side
of a link that you will find,
well somewhere around this video.
Click the link, follow the instructions
and it will be winging its way to you shortly.
The Scrum guide is rather explicit about the elements
that go into a proper Sprint Review.
I count seven bullet points and only one of those
is the demo, now really this should come as no surprise
in the same way that the daily Scrum isn't just an update,
the Sprint Review isn't just a demo.
Remember where we came in,
empiricism and those three pillars,
a daily stand up, that's just a series of updates,
may tick the box of inspection,
but there's no adaptation.
And similarly a Sprint Review that's only a demo,
again there's inspection maybe, but adaptation, not at all.
So if we're doing a Sprint Review
something must change, adapt,
or it's really been a big waste of everyone's time.
With that said let's go back to that list
of seven bullet points from the Scrum guide.
Number one, the product owner explains what
product backlog items have been done
and what has not been done.
Number two, the development team discusses
what went well during the Sprint, what problems it ran into
and how those problems were solved.
But we slightly overlapping with the retrospective.
Number three, the development team demonstrates the work
that it has done and answers questions about the increment.
Excellent the demo is in the list, good to know.
Number four, the product owner discusses the product
backlog as it stands,
he or she projects lightly target and delivery dates
based on progress to date, open brackets if needed.
Number five, the entire group collaborates
on what to do next so that the Sprint Review provides
valuable input to subsequent Sprint Planning.
Number six, review of how the marketplace
or potential use of the product might have changed,
what is the most valuable thing to do next.
And finally number seven,
and this one is a bit of a mouthful,
review of the timeline,
budget potential capabilities and marketplace
for the next anticipated releases of functionality
or capability of the product.
I wonder how you react to that list,
again I have to be honest and tell you that I've never
been involved in a Sprint Review
that was anywhere near that comprehensive
so I'm curious of those seven points that we've just
gone through which ones do you typically cover
during a Sprint Review, I'd be curious to know.
Let me know in the comments below,
a list of numbers, I'm guessing there might be
a short list of numbers, a list of numbers would do.
That's just about it on Sprint Review,
but keep watching there are many other videos
in this series on Scrum.
You might start with one of these two.