An Overview of the Scrum Process
Scrum is a simple framework that does not demand any special
tools or software. Here we explain how a project typically is run
using Scrum.
Product Backlog
Before we can start to use Scrum on a project, there needs to be
a Product Backlog.
A project's Product Backlog is, in its most basic form, a list
of everything that needs to be done in order for the project to
finished.
You can read more about creating and maintaining the Product Backlog
here.
Release Planning
Once we have a Product Backlog the Product Owner can start to
build a release plan for the project.
The Product Owner needs to take a look at the Product Backlog
and prioritise it with respect to the business value each item in
the Product Backlog has for the project stakeholders.
The Product Owner can then start to determine how much of the
Product Backlog needs to be developed in order to be considered a
releasable product and a rough idea of when it should be
released.
The Product Owner begins to specify the highest priority Product
Backlog items in such detail that they can be presented to the
Scrum Team for high level/rough estimation.
If the Product Backlog is large enough to cover a number of
Sprints, the Product Owner only specifies in detail those Product
Backlog items that will be a part of the coming Sprint and some or
all of the Product Backlog items for the next Sprint again. This is
to avoid wasting time specifying Product Backlog items that may not
end up being part of the final product due to changing
requirements.
It is the responsibility of the Product Owner to maintain the
Product Backlog for the duration of the project.
The Sprint
A Sprint is the name given to a period, typically 1 to 4 weeks
in duration, in which the Team works on delivering a number of
features pulled from the Product Backlog list. The result of a
Sprint should ideally be potentially shippable product.
At CoreWorks, we typically run 14 day Sprints, which start
on a Friday and run through to Thursday.
Why start the Sprint on a Friday? Teams returning from a weekend
are motivated and eager to start doing the work they love doing.
However, starting a new week off with a planning meeting lasting
several hours really takes the edge off the Team's enthusiasm. We
feel the best way to serve the Team is by running Sprint Planning
Meetings on a Friday so when the Team comes in on a Monday morning
they are fully loaded and ready to start the Sprint.
A sprint kicks-off with a Sprint Planning Meeting, followed by a
number of days working on tasks from the Sprint Backlog, and ending
with a review of the Sprint.
Sprint Planning Meeting
On the first day of a Sprint the Product Owner and Team meet for
the Sprint Planning Meeting. The Sprint Planning Meeting is held in
two parts:
- Product Backlog Presentation
- The Sprint Backlog
Product Backlog Presentation
In the first part of the Sprint Planning Meeting, the Product
Owner presents the Product Backlog to the Team. The Product Owner
does so in order of priority and it is the Teams job to ask
questions to ensure they have enough information for each item in
the Product Backlog to break them down into Tasks.
The Sprint Backlog
The Sprint Backlog is the Team's list of features they are
committed to work on in the Sprint. It is generated by the Team by
pulling the highest priority item on the Product Backlog list,
breaking out tasks for that item, committing to the item and
repeating the process until the Team cannot commit to more work. In
this way the Team decides how much work they can commit to for the
Sprint.
Sprint Daily Routine
Once the Scrum Team has a Sprint Backlog broken down into tasks,
the Sprint Backlog Items/Stories) and their tasks are placed upon
the Scrum Task Board. The Scrum Task Board is a central component
of daily life for the Scrum Team and is used to track the Scrum
Teams progress throughout the Sprint and is the gathering point for
the daily Scrum meeting.
Daily Scrum
Each day the Team holds a Daily Scrum Meeting. Here each Team
member is asked three questions:
- What did you do yesterday?
- What will you do today?
- Is there anything standing in your way?
The meeting centers around the Scrum Task Board, which is
updated by Team members, and lasts a maximum of 15 minuets and is a
way for the Team stays informed on what each member i working on
and to identify any issues that are getting in the way of the Teams
progress.
Sprint Burndown Chart
The Sprint Burndown Chart is used to daily record the Teams
progress on the work the Team has committed to deliver by the end
of the Sprint. It gives a quick way to determine if the project is
on track or not and because it is updated every day, it allows the
Team to respond, if the project is running behind, and get the
project back on track.
The Sprint Review
Each Sprint finishes with a review made up of two parts.
Sprint Review - The Sprint Demo
The purpose of the Sprint Demo is to allow the Scrum Team to
demonstrate how they have succeeded in meeting the Sprint's
goal.
Sprint Review - The Sprint Retrospective
The second part of the Sprint Review, called the Retrospective,
is for the Scrum Team to look back at their performance for the
Sprint and ask themselves three questions:
- What should we keep on doing?
- What should we stop doing?
- What should we try in the next Sprint?
We find it is useful to have these questions written up on a
whiteboard along with the input from the Team. It is also a good
idea to have a "parking space" or issues raised that are out of
scope and which need to be discussed but at another time out side
of the retrospective.
The Sprint Retrospective is normally exclusively for the Scrum
Team. The Scrum Team uses the information gathered to improve their
performance in the coming Sprint.
Repeat until done
The Scrum process then repeats until the project is
completed.