[Applause]
So thank you everyone for coming to our 300th Sprint Review and as we know Sprint
Review is a very good opportunity for all of you to blame our Scrum team for
not meeting their commitments. You can also find a scape goat here and also
cajole our Scrum team to increase the velocity in the next Sprint. And even
better, you can also compare our Scrum team's velocity with the other Scrum
team's velocity. So in today's Sprint Review we will demo you all of the
functionalities that we have completed and also how we failed to hit our target
velocity. Let's do this. Yeah yeah yeah yeah yeah.
Thank you for the long introduction and can you just move on and show us what
you completed this Sprint and demo us the shopping cart functionality please,
because that is the most important functionality to be completed this
Sprint. So basically, what will happen is once you finish shopping you can click
this checkout button and then you will be prompted with this payment form
is that understood? Wait wait wait wait wait, before you proceed
why is the checkout button blue instead of red? I thought we agree on blue? Many
many minutes later. You know we can just have a purple button instead of arguing
whether we should have blue or red button? So why do you have to be
redirected to the payment form instead of popping up the dialog box instead?
But that's not what you requested last Sprint?
How can you change your mind? You can't do this to us? Three hours later. Can you
re-train us on Scrum fundamentals again? Isn't Sprint Review basically an opportunity
for us to keep on changing our mind because we're lacking visions and goals?
So can you tell me why your team didn't deliver the payment using American
Express? I thought you committed to do it during Sprint Planning? Many hours later.
Did the junior developers take enough work this Sprint or are they also slacking?
See I've been telling you, this is the problem with self-management, you can't
trust the developers to self-manage, they must be managed, they're not mature
enough. There's no but. you have to do as I told you, I'm the CEO
of the company, you hear me? So what you just saw there
it's not a Sprint Review folks. Even though from my experience, I have
seen many Sprint Reviews similarly like that.
Now if you want to know how a Sprint Review should look like, stick around,
because in today's video we will learn about the Sprint Review.
Before we learn more about the Sprint Review, I would like to greet you first,
awesome people. How has your week been going so far folks? I hope your customers
are praising you because they get tons of value from using your product. For
those of you who have been following this channel, welcome back to my channel.
And for those of you who are new to this channel, my name is Joshua Partogi, I'm a
Professional Scrum Trainer (PST) based in Brisbane, Australia. Welcome on board to
our community of passionate change makers. Before we start today's learning,
let's go back to the past and recall what I said on my video about the
increment in Scrum. Folks if the Sprint Review at your
workplace is still treated as a User Acceptance Testing or UAT session,
you have a lot of homework to level up the game. Now if you haven't watched my
video on increment in Scrum, click the link up here to watch that video first.
Because in today's video I will not repeat whatever that has already been
covered on that video. I have broken down today's video into three segments. In the
first segment I will bust the myths around Sprint Review. In the second
segment I will answer some questions related to Sprint Review. And in the last
segment, we will see an illustration of how a Sprint Review should look like. So
let's start with the first segment and bust a myth around Sprint Review. There is
a myth that the Sprint Review is like a User Acceptance Testing or UAT or demo
session where the Scrum team will demo the functionalities while the user will
test the increment. Some people map Sprint Review to UAT or demo session. The
Sprint Review is not about testing or demoing the output of the Sprint. As
written on Scrum Guide, the purpose of the Sprint Review is to inspect the
"outcome" of the Sprint and determine future adaptations.
Focusing on outcome during Sprint Review is essential. So from my observation, in
some cultures outcome and output is perceived as the same thing. I'm not
going to discuss the differences between outcome and output again in this video
because I have already made a video about it. Now if you haven't watched that
video on outcome over output you can click the link up here to watch that
video first because outcome will be highly emphasized throughout today's
video. Now within teams who still do manual acceptance testing, I mentor them
on how to practice acceptance testing driven development or ATDD using tools
like cucumber. We all know that not only manual acceptance testing is error prone,
it's also painful. Acceptance testing whether it's done manually or automated
should be done before rather than during the Sprint Review. During Sprint Review,
the increment should already be at a releasable state. If the acceptance
testing has already been automated, acceptance testing can be executed
multiple times in a Sprint with no pain. There is a myth, that Sprint Review is a
phase gate or approval process before the increment can be released to the
production environment. In Scrum Guide version 2020, it is stated that the
Sprint Review is not a gate to releasing value. Scrum teams who already practiced
DevOps will release the increments multiple times before the Sprint Review
using continuous integration, containerization, feature flagging,
infrastructure as code and canary release techniques. I've already made a
video on how to use Scrum with devops, if you haven't watched that video you
can click the link up here to watch that video. There is a myth that the Sprint
Review is the only time for the Scrum team to get feedback from the
stakeholders and also from the customers. The Sprint Review is a collaborative
event for people in the company to foresee how they can stay competitive in
the market. Before the Sprint Review, the Scrum team can get feedback from the
customers as much as needed so that the Sprint goal can be achieved. You can call
this feedback gathering session with any name you like and consider it as a
complimentary practice for Scrum. Now in this segment, I will answer the questions
that I commonly get after I busted the myths that we have just discussed in the
previous segment.
[Music] Besides the Scrum team, anybody who has a
stake in the product should attend the Sprint Review. This includes, but is not
limited to, the actual customers, the senior management, the investors,
delegates from other departments such as legal, risk, marketing, corporate
governance, call center, etc. The point is, if people have a stake or an interest in
the product being developed by the Scrum team, they should attend the Sprint
Review and collaborate together with the Scrum team.
[Music]
As written on Scrum guide, the Scrum team presents to the stakeholders. Now as the
Product Owner is part of the Scrum team and also accountable for the value of
the product, I personally prefer the Product Owner to take the stage and
present the outcome of the Sprint to everyone who attends the Sprint Review.
And also keep in mind, as written on Scrum Guide, the Scrum team should avoid
limiting Sprint Review only for presentation. The Sprint Review is about
determining future possibilities based on the present situation.
[Music]
The first reason is because in a corporate setup we need to book the
senior management and the customer's time several weeks ahead and sometimes
even several months ahead. We cannot just pull these people in an ad-hoc manner.
When there is a regular cadence to attend the Sprint Review, people who have
a stake in the product can easily create recurring events for the Sprint Review
in their calendar. Now the second reason is because the Scrum team must align the
product goal and the Sprint goal to the corporate business strategy. The Scrum
team also needs to hear insights from the other departments about the current
market situation. There's no point in continuously releasing without knowing
what's happening in the market. There's no point in going fast if you don't know
your current position and your destination. The Sprint Review provides
transparency about the outcome of the Sprint and also the current market
situation.
[Music]
As the Sprint Review has never been about acceptance testing or demoing the
completed output, the Scrum team should present outcome metrics or
Evidence-Based Management metrics during Sprint Review to the stakeholders. Now I
have already made a video on EBM metrics. If you haven't watched that video you
can click the link up here to watch that video. And after you watch that video,
make sure you download a sample EBM dashboard by clicking the link on the
description section down below. You can use the sample EBM dashboard as an
inspiration for creating your own EBM dashboard. And folks don't forget to also
read the latest EBM guide from Scrum.org website. Now let's look at how a Sprint
Review should look like in the next segment. So thank you everyone for
joining our Sprint Review. For those of you who don't know me, I'm the Product
Owner of our team and today we will seek possibilities to increase the value of
our product based on the current state of the market. I'll present to you the
outcome that our product has delivered to our customers and I will also present
to you the Evidence-Based Management metrics. Let's do this. Oh yeah, thanks for
that John. So can you tell us the outcome of this Sprint. Yeah I would definitely
be interested in this Sprint outcome. Thanks Phil for the question. So in this
Sprint our team has released 20 increments five times into our
production box. We have automated all of the testing and all of the deployment
process to speed up the process in our value stream. Five percent of our
customers have already seen this increment but unfortunately only ten
percent out of those five percent have started using it. So how about the
download and the sign up rate, did the new functionality entice the market to
sign up and download our product? Good question. So our download and sign up rate
have also spiked about 15 percent this Sprint. That's really awesome. So today, why don't
we discuss the penetration strategy to increase our consumer usage index and
also the stickiness rate? Shall we? So I think next Sprint you can
uncheck the feature toggle and open up the functionalities to more consumers.
Let's see if that will increase our consumer usage index and stickiness
metric. So before we close today's Sprint Review can you show us the remaining
budget? Do you think we have enough budget to
achieve the product goal? So looking at our remaining budget we have $150,000
left and based on the team's historical performance, with this amount of budget
we can stick around for another three Sprints. So how many more Sprints to
achieve the product goal? So looking at our product goal and also our team's
historical performance, based on our forecasts we may need another six
Sprints to achieve the product goal. So okay everyone, looking at our current
situation at the management level we need to work out how to pump up
additional two hundred thousand dollars and the product goal must be achieved. So
in general, what you just saw is what should happen during every Sprint Review.
The Sprint Review should focus on the outcome rather than the output of this
Sprint. When the Sprint Review is focused on outcome over output, it's actually not
much different to the corporate Monthly Review or Quarterly Review meeting at
your workplace. Before the Sprint Review, the increment should already meet the
Definition of Done or at a state where it can be released. Scrum teams who
already practiced DevOps took 10 steps further by releasing the increments
multiple times in a Sprint so the outcome metrics can be available for
Sprint Review. Besides outcome metrics, during the Sprint Review the
participants should also look at the market condition, customer feedback,
remaining budgets, how far is the company towards achieving the product goal and
whether additional funding is needed to achieve the product goal. The Product
Goal is the center of Scrum because in Scrum both the Sprint Goal and the
Product Backlog are tightly coupled to the Product Goal watch my videos on the
Product Goal, the Product Backlog and also the Sprint Goal that are available
on this channel. So that is all from me today folks. If you have any more
questions about the Sprint Review just leave a comment in the comment section
down below. In today's video I didn't go into the technical details of DevOps
practices that make an outcome driven Sprint Review possible but I do hope
today's video gives you some inspiration to level up how the Sprint Review will
be conducted at your workplace in the near future. And you know the drill folks
don't forget to do all of those things that you must do after watching videos
on youtube. Subscribe to this channel if you haven't already. Click the like
button down below. And watch other videos on this channel by clicking the
thumbnails here and also down there. See until my next video folks. Until then,
stay safe and don't forget to stay awesome.