- We're dissecting Scrum,
taking a look at it piece by piece.
Today it's the turn of Sprint Planning.
There will be a cheat sheet
and there will be some controversy.
Welcome to Development that Pays.
My name is Gary Straughan and today
we are indeed diving into Sprint Planning.
Sprint Planning is one of Scrum's five events.
What we use to describe as ceremonies.
The others being Daily Scrum, Sprint Review,
Sprint Retrospective and the one that wraps them all up
and ties them neatly in a bow, the Sprint itself.
The start of Sprint Planning marks the beginning
of the Sprint and the purpose of Sprint Planning,
actually, let's get that straight from the Scrum Guide.
The work to be performed in the Sprint
is planned at the Sprint Planning.
Fair enough.
Who's involved?
The plan is created by the collaborative work
of the entire Scrum Team.
We'll take a look at that collaboration
in just a moment after we've looked at the inputs
and the outputs to Sprint Planning.
The most obvious inputs and outputs
are the Product Backlog in
the Sprint Backlog
and the Sprint Goal out.
There are a couple of less obvious inputs,
but again, the Scrum Guide is there to help us out.
The input to this meeting is the Product Backlog,
the latest product Increment, the projected capacity
of the development team during the Sprint
and the past performance of the development team.
That mention of capacity reminds us that a Product Backlog
in Scrum comes with a certain set of assumptions.
An assumption that the items are ordered, prioritized
and that the items have been estimated,
at least the items towards the top
of the list have been estimated.
Okay, I think we're ready to do some Sprint Planning.
The Scrum Master calls the meeting
and the development team in here,
the Scrum Guide is super clear,
only the development team selects high priority items
from the top of the Product Backlog.
It's important to note that they may or may not select
the items that are right at the top of this list.
Part of the art of Scrum is selecting items
that are in some way coherent.
Items that make sense to develop together.
So far it sounds like this meeting
might be a little on the boring side
for the product owner but not a bit of it.
The product owner can help clarify
the selected Product Backlog items and make trade-offs.
I mentioned earlier this notion of selecting coherent items
and this ties in nicely with the Sprint Goal.
The Scrum Guide again.
During Sprint Planning,
the Scrum team also crafts a Sprint Goal.
The Sprint Goal is an objective
that will be met within the Sprint
through the implementation of the Product Backlog
and it provides guidance to the development team
on why it is building the Increment.
Excellent, we have our Sprint Goal
and we have our selected items,
our Sprint Backlog, or, or do we?
Actually, we're not quite there yet.
In fact, according to the Scrum Guide,
you're only halfway there.
I'll say more about that in a second
after I tell you how to get your hands on this.
This is the Scrum Cheat Sheet.
In the description below, you'll find a link,
click that link, follow the instructions
and the cheat sheet is all yours.
Alright, back to the action.
So we selected some items from the Product Backlog
and we've established a Sprint Goal
and in any Sprint Planning session
that I've been involved with,
that's been the end of the story.
The team will be up on their feet
and heading to the nearest coffee machine,
but apparently, I and many of my colleagues
have been getting this very wrong.
The Scrum Guide is really clear that Sprint Planning
has, not one, but two parts to it.
In fact, the Scrum Guide refers to these as topics
and topic one is what can be done in the Sprint?
But topic two is how will the chosen work get done?
Let's see what it says about this in detail.
Having selected the Sprint Goal
and selected the Product Backlog items for the Sprint,
the development team decides
how it will build this functionality
into a done product element during the Sprint
and standby for another surprise.
The Product Backlog item selected for the Sprint plus
the plan for delivering them is called the Sprint Backlog.
Did you get that?
Turns out that the Sprint Backlog is more
than just the selected subset of the Product Backlog,
it's that subset plus a plan for
how that subset will be delivered.
So not just the what but also the how.
Clearly, I've been getting this wrong
for a very long time, but what about you?
For you, is Sprint Planning just a process of selection
or do you go on and create that all important plan?
Be very curious to know and let me know
in the comments below and if you're interested in Scrum,
keep watching, there are many other videos in this series
and you can start off with one of these two over here.
Thanks indeed for watching.
I'll see you next time.