- [Narrator] We've looked at scrum as a whole
and now we're going through the component parts one by one.
Today it's the turn of the Sprint Backlog
and yes, there will be a cheat sheet.
Welcome to Development That Pays
my name is Gary Straughan
and if we're meeting for the first time please consider
subscribing, and remember to hit the bell icon
so you don't miss a thing.
The Sprint Backlog is a list of things
that the development team will work on during
the Sprint, it's created once per Sprint
and the event where it's created is the
Sprint Planning Meeting.
The Product Backlog, the master list of things to do,
provides the input.
I think I'm on safe ground so far,
let's just check in with the Scrum Guide.
The Spring Backlog is the set of Product Backlog
items selected for the Sprint.
So far so good.
Two properties of the Product Backlog and its contents
are useful slash relevant
when it comes to selecting items.
It's a prioritized list with the most important
items appearing towards the top,
and the items, if not all of them, but certainly those
towards the top of the list are sized.
I'm gonna represent the relative size
like this.
It's common practice to size using story points.
Although you won't find a mention of story points
in the Scrum Guide.
And if the team has a few Sprints under its belt
it will have an idea of its Capacity,
in other words the number of story points
it can handle, it can process during one Sprint.
A prioritized list of sized things to do
and a Capacity?
Could it be that creating a Sprint Backlog
is as simple as taking items from the top of
the Product Backlog until the number of
story points is equal to the Capacity?
Perhaps with a bit of jiggling around at the end
to fill the space.
If it was as simple as that there'd be a button to do it
in Jira.
There's not a button for that.
Is there a button for that in Jira?
Not a clue.
Let's take half a step back here, it's the Development
Team's job to, by the end of the Sprint,
produce an Increment, to give it its Sunday name,
a potentially, I never say that right,
to produce a Potentially Releasable Increment.
So it makes sense as far as it's possible,
to select items from the Product Backlog that are
complementary, coherent, or pulling in a similar direction.
Pulling towards a Sprint Goal.
The Scrum Guide ties these things together quite nicely.
The Sprint Backlog is the set of Product Backlog items
selected for the Sprint, plus a plan for delivering
the product Increment and realizing the Sprint Goal.
One thing to note that it is the Development Team
and the Development Team alone that selects items
for the Sprint Backlog.
Yes the other members of the team have an influence
but the final say goes to the Development Team.
And there's another important point concerning adding work
to the Sprint Backlog during the course of the Sprint.
So what do you reckon? Is it okay to add work to the
Sprint Backlog during a Sprint?
I'll let you mull that over for a second while I
remind you that there is a cheat sheet to go with this
series on Scrum, and it is imaginatively named
the Scrum Cheat Sheet, and you will find a link to it
somewhere in the description below, click the link,
follow the instructions, and it's all yours.
Back to the question can work be added to the
Sprint Backlog during the course of the Sprint,
well the answer is no and it's yes.
The Sprint Backlog is Scrum's way of limiting
work in progress, and limiting work in progress
is important for getting things done and getting things
done quickly with a minimum of context switching.
So when Sprint Planning is over, the Sprint Backlog
is locked down. Any attempt by anyone outside
the Development Team to add new work into the
Sprint Backlog should be vigorously resisted,
in fact it's one of the Scrum Master's key roles
to protect the Sprint Backlog from external influence.
But that's not to say that the Sprint Backlog
is fixed, agile development is a process of discovery,
and it's not uncommon for new work to be uncovered
during the course of the Sprint, new work that is required
in order to produce a Potentially Releasable Increment.
Hey I said it that time.
The Scrum Guide puts it like this,
the Development Team modifies the Sprint Backlog
throughout the Sprint, and the Sprint Backlog
emerges during the Sprint.
The emergence occurs as the Development Team
works through the plan and learns more about the work
needed to achieve the Sprint Goal.
In short, work can be added to the Sprint Backlog
but only by the Development Team.
Thank you very much for watching, if you enjoyed
this episode please give it a thumbs up,
share it with your network and remember to hit the logo
right here for a brand new episode every Wednesday,
sometimes every other Wednesday.
Look forward to seeing you next time cheers for now.