- We're dissecting Scrum
to take a look at it piece by piece.
Today, it's the turn of the event
that's hiding in plain sight:
The Sprint.
Welcome to Development That Pays,
my name is Gary Straughan,
and if we're meeting for the first time,
please consider subscribing,
(bell pings) and hit that bell icon,
so you don't miss a thing.
Our journey has brought us to The Sprint,
arguably the defining feature
of Scrum.
The Sprint is a wrapper for the other four events.
Sprint Planning, Daily Standup, Sprint Review,
and Sprint Retrospective.
Did you know that all five Scrum events are time-boxed?
Well, they are, and nowhere is that more evident
than with the Sprint itself.
The Scrum Guide tells us that the maximum duration
for a Sprint, is one calendar month.
And while some teams go as short as one week,
most teams have found that two weeks
is just about the sweet spot.
I started out by saying that the Sprint is
the defining feature of Scrum,
but what's it's purpose? What's it's intent?
The Scrum Guide lays it out, "Each Sprint my be considered
"a project with no more than a one-month horizon.
"Like projects, Sprints are used to accomplish something.
"Each Sprint has a goal of what is to be built,
"a design and flexible plan that will guide building it,
"the work, and the resultant product increment."
That mention of a project there reminds us of Waterfall,
where we might Design everything, Build everything,
Test everything, Release everything, over a period of time
that might amount to months or even years, and that's risky.
Scrum chunks this down into units of time,
but still requires that all,
or at least most, of the processes are present.
In each Sprint we can expect to Design, Build and Test.
What about Release?
Well Scrum doesn't require us to Release,
but it does require that every Sprint we build
what is termed as a Potentially Releasable Increment.
Whether or not this increment is actually released,
is a decision for the Scrum Team.
As a quick aside here, there's nothing in the Scrum Guide
that says that we must wait to the end of a Sprint
before releasing.
Continuous integration, continuous deployment approaches
are more than welcome.
So we looked at Waterfall,
and we looked at Scrum's
chunking of time,
but what's the benefit?
Well, we've already touched on one,
and that is to do with risk.
If we find that we've run off in the wrong direction,
well at least we only did so for a month or less.
And the benefits keep coming.
At the end of each Sprint we Inspect
and Adapt,
and that's built into another Scrum event,
the Sprint Review.
The Sprint Review is one of the main ways we ensure
that the product improves over time.
In Waterfall, remember: Design everything, Build everything,
Test everything, we get to play the game exactly once.
In Scrum, we get to play the game Sprint, after Sprint,
after Sprint, after Sprint.
This gives us the opportunity to get better
at playing the game.
And again, Scrum doesn't leave this to chance,
it's built in to another event, the Retrospective.
I'm gonna break in once again just to say
that there is a cheat sheet to go along with
this series on Scrum.
The cheat sheet is imaginatively titled,
"The Scrum Cheat Sheet."
Getting your hands on a copy is simplicity itself.
In the description below, you will find a link.
Click the link, follow the instructions, and it's all yours.
Going back to something I mentioned earlier,
Sprints are used to accomplish something.
That something being, the Sprint Goal.
And one of the ways Scrum does this is to, in effect,
insulate the team so that it can concentrate
and get work done.
And although Scrum doesn't preclude changes
during the Sprint, it certainly limits them.
Here's what the Scrum Guide says,
"No changes are made that would endanger the Sprint Goal."
Of course, it's quite normal for the team itself
to make changes as it moves through the Sprint
and discovers new things about the work,
and the Scrum Guide words this rather nicely,
"Scope may be clarified and renegotiated between
"the Product Owner and Development Team as more is learned."
So this chunking of time
into the Sprint,
brings with it some really good stuff: a reduction of risk,
the improvement of the product over time,
and the improvement of processes over time.
We get better at playing the game.
What's not to like?
Well, not much, but these things don't come for free.
The team needs to figure out what's achievable
within each Sprint.
So they need to spend time sizing, estimating,
backlog items,
so they know how many of them can fit into the Sprint.
That's an overhead that you won't find
in all agile frameworks.
And what happens if the team gets the estimates wrong?
We have a tendency towards optimism, so it's not unusual
for the team to approach the end of the Sprint
and see that there's still rather a lot to be done.
Is it okay just to stretch the Sprint just a little bit
in order to fit them in?
Well, no it's not.
We never increase the size of the Sprint.
However, if things get really hairy, we do have the option
of canceling the Sprint.
Here's what the Scrum Guide says about that:
"A Sprint would be canceled
"if the Sprint Goal becomes obsolete.
"This might occur if the company changes direction
"or if market or technology conditions change.
"In general, a Sprint should be canceled
"if it no longer makes sense given the circumstances."
Dramatic stuff indeed but,
given that a Sprint is only a few weeks long anyway,
Sprint cancellation is rare.
Question of the week,
"In your team, how long is your Sprint?"
Let me know in those comments below, and keep watching,
there are many other videos in this series on Scrum,
including the two that you should see around me somewhere.
See you next time, cheers for now.