Scrum - Summary

The first day: Sprint Planning
The whole team,

including the Product Owner, meet on the first day of the Sprint and conduct
a Sprint Planning session. This is the very first thing to happen as soon as
the Sprint commences.
Preparation
Sprint Planning ought to be prepared for. The most important preparation is

to ensure that the Product Backlog has been refined to an appropriate level
of detail, with estimates and acceptance criteria (this is the purpose of
Product Backlog Refinement). Next, the Product Owner should have
ordered the work on the Product Backlog, and have a general idea of how
to negotiate a valuable Sprint Goal with the team. The options for
negotiating a Goal should also have been considered during Refinement,
and reflected in backlog ordering. Also, the team should have an idea of
their capacity for this Sprint, which is to say, how much work they believe
they can take on. They may be able to use their experience with previous
Sprints to help them ascertain the size of this budget.
First plan the value that will be delivered

Each Sprint should result in a valuable increment of completed work, fit and
ready for immediate release. The Product Owner is wholly accountable for
what “value” means, and ought to have ordered the Product Backlog in
such a way that value can be maximized by the team, sprint-by-sprint. The
first thing the team must do is therefore to plan which items from the
Product Backlog should be worked on in this Sprint, so that the best value
can be delivered by the end of it.
To do this, the team work with the Product Owner to select the most
valuable items from the Product Backlog which fits their projected capacity
for the Sprint. Bear in mind that each item on the Product Backlog ought to
have been given an estimate by the team, so they will know roughly how
much work is likely to be involved.
Be sure to agree a Sprint Goal
This selection of work should be cohesive, and not just a grouping of

unrelated and disparate items. Remember that a Sprint is a time-boxed
opportunity to achieve something significant. For example, by the end of the
Sprint a coherent feature may have been delivered, or a significant risk will
have been mitigated. The Sprint Goal is a simple expression of this
purpose, of the overarching significance of the work selected, and the
coherence behind the selection.
A good Sprint Goal will allow the team to demonstrate focus and
commitment, and allow collaboration and the re-planning of work so it is
met.
Next plan how the work will be done

A Sprint Backlog is more
than just a selection of work with an end goal in mind. It is also a plan for
how that goal will be achieved, and how the associated work will be
performed. This can be done by identifying and ordering the technical tasks
that are likely to be involved. In effect the Sprint Backlog is a plan for
meeting the Sprint Goal, and a forecast of the work that will have to be
done.
The Product Owner does not need to be present for this part of Sprint
Planning, as it is up to the team to plan this forecast at a technical level.
However, the Product Owner should be available, even if only remotely, to
answer any questions the team may have, and to provide any clarification
that may be needed about the scope of the work. If more than one release
is expected during the Sprint, this should be agreed with the PO and
accounted for in the Sprint Backlog.
By the end of Sprint Planning, a team should be confident that it has made
a good forecast of the work that will be needed to meet the Sprint Goal. It
will have captured that plan in the Sprint Backlog which the team wholly
owns. The team should be able to begin implementing that plan
immediately and with a clear understanding – such as a Sprint Burndown -
of how much work remains at any given point.
Each day, every day
Once the
team have planned their Sprint Backlog they can start work. If they have
planned things out as tasks, they will collaborate with each other, as a
team, to make sure that those tasks are completed. They’ll be able to track
their progress by using their task board and their Sprint Burndown of work
remaining.
Each team member will be sure to keep the Scrum Task Board and the
Sprint Burndown updated, so the information can be relied upon by others.
An information radiator should always tell the truth.
Hold a Daily Scrum
Every working day, at the same time, the Development Team will meet and
plan what they will do to bring them closer to the Sprint Goal. This meeting
is called the Daily Scrum and it should never take more than 15 minutes.
Only Development Team members should

participate, as the plan of work belongs entirely to them. It is a time-boxed
opportunity to re-plan the Sprint Backlog as a result of new discoveries and
lessons learned during the Sprint. The whole team should participate. Each
team member should be able to account for:
• What they did yesterday to help the team meet the Sprint Goal
• What they intend to do today to help the team meet the Sprint Goal
• Any impediments which are getting in their way
By the end of the Daily Scrum, the team should have a clear plan for the
next 24 hours and an understanding of how they will need to collaborate in
order to achieve it. They should also have a list of any impediments which
require the Scrum Master’s attention.
Refine the Product Backlog
In Scrum, Product Backlog Refinement is not a

formal event but an ongoing activity - the process of adding detail, order,
and estimates to Product Backlog Items such as User Stories. It’s up to
Scrum Teams themselves to decide how often to do this, although it’s
certainly a good idea for them to build refinement into their daily routine.
Refinement shouldn’t take more than 10% of a team’s total time during a
Sprint. For most teams, half an hour a day may be adequate although some
may prefer to spend an hour or two a couple of times a week. The important
thing is to make sure that the Product Backlog is refined in a timely manner
so that Sprint Planning can occur without impediment. The whole team,
including the Product Owner, should participate.
A refinement session typically begins with the Product Owner presenting

the current Product Backlog to the team. The backlog may be held in a
number of forms, such as an electronic Scrum Board or other collaboration
tool, or it may simply be a spreadsheet. A projector or shared screen can be
very useful.
The team start at the top of the Product Backlog and

work their way downwards, refining each item in turn. They’ll examine each
one and discuss its scope, and the acceptance criteria that will be
necessary for its completion. Each item will then be estimated using a
technique such as Planning Poker. A large item may be broken down into
smaller ones which capture greater detail. Epics may be decomposed into
user stories, for example.
The team stop once the session’s time-box runs out. They will recommence
where they left off the next time, eventually starting at the top again so the
backlog is kept up to date.
Always collaborate
In agile practice, team members never work in isolation – if they did, they
wouldn’t be a team. In fact, teamwork is so important that the role is
Development Team rather than Developer.
This means that each Development Team member must collaborate with
his or her peers throughout the day, as they are jointly responsible for the
progress of work. Any problems or failures are jointly owned by the team,
as well as their successes. Collaboration is not something which is
restricted to events such as the Daily Scrum, but applies to everything the
team does throughout each entire Sprint.
Examples of collaboration include:
• Helping peers to complete work in progress before bringing in new

work from a backlog
• Pair programming, such as taking it in turns to use the keyboard and
helping and checking each other’s work
• Peer review
• Asking for help, and being keen to give it
• Going to where the work is and helping, instead of waiting for work to
be passed over to them
• Making sure that all work does in fact meet the Definition of Done
• Calling a Scrum in order to resolve problems which need the team’s
immediate attention
• Raising impediments to the Scrum Master so they can be handled in
a timely manner
• Updating a Scrum Task board and burndown chart so that the
information is up-to-date and can be relied on
• Skill and knowledge sharing
The final day: Review and Retrospective

Hold a Sprint Review
If a team has collaborated efficiently, they’ll have

worked together to meet the Sprint Goal, managing any risks and adjusting
their plans as necessary. They’ll have demonstrated control throughout the
Sprint through an even burndown of work remaining, where each member
saw it as their personal responsibility to help complete work in progress.
They’ll have a valuable increment to demonstrate to the Product Owner and
any invited stakeholders. A Review is something a team should look
forward to.
It’s also something a team must prepare for. Enough time must be allowed
for a demonstration of the work which has been performed. Tasks may be
planned on a Sprint Backlog for this purpose, to make sure that the Review
does justice to the work done and the value which is now available. Also, if
the Product Owner thinks it would be a good idea to invite stakeholders,
then those invitations ought to have been sent. The review is an opportunity
to celebrate the work which has been done and to showcase their
accomplishments, so confidence is inspired and a continued investment in
the team might be justified.
A Sprint Review is also an inspect-and-adapt opportunity. It’s a good time

for the Product Owner to explain how well the product is performing, to get
feedback first-hand from any invited parties, and to draw any lessons which
might be used to improve the Product Backlog further. If any work has not
been completed, for whatever reason, then this will also be reviewed and
re-estimated on the Product Backlog for possible planning into future
sprints.
Then conduct a Sprint Retrospective
The Sprint Review looked at the Product and

the value delivered, at the work which has been done, and honestly and
candidly at any work which wasn’t done, whatever the reason.
The next thing to do is to conduct a Sprint Retrospective. A Retrospective
considers the process which the team is following. Are they working as
effectively as they can? It’s generally best to hold the Retrospective
immediately after the Review, because the former can introduce ideas for
consideration in the latter.
The whole Development Team, the Product Owner, and the Scrum Master
must all attend the Retrospective, because everyone is jointly responsible
for the success of the team’s work. It’s really important to have a free and
open session which gets to the heart of any problems and identifies actions
which will help to resolve them. A Retrospective may begin with the
following declaration:
“Regardless of what we discover, we understand and truly believe that

everyone did the best job they could, given what they knew at the time, their
skills and abilities, the resources available, and the situation at hand.”
In a “Retro”, everyone has an equal voice. One approach, which the Scrum
Master may facilitate, is to identify:
• Things which went well

• Things which didn’t go so well
• Ideas for improvement
• Shout-outs for team members who did something exceptional
Establishing a time-line can help jog attendees’ memories about significant

events during the Sprint.

Scrum - Summary

Uploaded by

Copyright:

Available Formats

Scrum - Summary

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scrum - Summary

Uploaded by

Copyright:

Available Formats

The first day: Sprint Planning

The whole team,

Sprint Planning ought to be prepared for. The most important preparation is

First plan the value that will be delivered

Be sure to agree a Sprint Goal

This selection of work should be cohesive, and not just a grouping of

Next plan how the work will be done

Hold a Daily Scrum

Only Development Team members should

Refine the Product Backlog

In Scrum, Product Backlog Refinement is not a

A refinement session typically begins with the Product Owner presenting

The team start at the top of the Product Backlog and

Examples of collaboration include:

• Helping peers to complete work in progress before bringing in new

The final day: Review and Retrospective

If a team has collaborated efficiently, they’ll have

A Sprint Review is also an inspect-and-adapt opportunity. It’s a good time

Then conduct a Sprint Retrospective

The Sprint Review looked at the Product and

“Regardless of what we discover, we understand and truly believe that

• Things which went well

Establishing a time-line can help jog attendees’ memories about significant

You might also like