What is Scrum?

Scrum is an agile approach to software development. Rather than a full

process or methodology, it is a framework. So instead of providing
complete, detailed descriptions of how everything is to be done on the
project, much is left up to the software development team. This is done
because the team will know best how to solve the problem they are
presented. This is why, for example, a sprint planning meeting is
described in terms of the desired outcome (a commitment to set of
features to be developed in the next sprint) instead of a set of Entry
criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as
would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum
team is self-organizing in that there is no overall team leader who
decides which person will do which task or how a problem will be
solved. Those are issues that are decided by the team as a whole. The
team is cross-functional so that everyone necessary to take a feature
from idea to implementation is involved.
These agile development teams are supported by two specific
individuals: a ScrumMaster and a product owner. The ScrumMaster can
be thought of as a coach for the team, helping team members use the
Scrum framework to perform at their highest level. The product owner
represents the business, customers or users and guides the team
toward building the right product.
Scrum projects make progress in a series of sprints, which are
timeboxed iterations no more than a month long. At the start of a
sprint, team members commit to delivering some number of features
that were listed on the projects product backlog. At the end of the
sprint, these features are done--they are coded, tested, and integrated
into the evolving product or system. At the end of the sprint a sprint
review is conducted during which the team demonstrates the new
functionality to the product owner and other interested stakeholders
who provide feedback that could influence the next sprint.

What are the main activities in Scrum?

The sprint itself is the main activity of a Scrum project. Scrum is an
iterative and incremental process and so the project is split into a
series of consecutive sprints. Each is timeboxed, usually to between
one week and a calendar month. A recent survey found that the most
common sprint length is two weeks. During this time the team does
everything to take a small set of features from idea to coded and
tested functionality.

Scrum

Page 1 of 20

The first activity of each sprint is a sprint planning meeting. During this
meeting the product owner and team talk about the highest-priority
items on the product backlog. Team members figure out how many
items they can commit to and then create a sprint backlog, which is a
list of the tasks to perform during the sprint.
On each day of the sprint, a daily scrum meeting is attended by all
team members, including the ScrumMaster and the product owner.
This meeting is timeboxed to no more than fifteen minutes. During that
time, team members share what they worked on the prior day, will
work on today, and identify any impediments to progress. Daily scrums
serve to synchronize the work of team members as they discuss the
work of the sprint.
At the end of a sprint, the teams conducts a sprint review. During the
sprint review, the team demonstrates the functionality added during
the sprint. The goal of this meeting is to get feedback from the product
owner or any users or other stakeholders who have been invited to the
review. This feedback may result in changes to the freshly delivered
functionality. But it may just as likely result in revising or adding items
to the product backlog.
Another activity performed at the end of each sprint is the sprint
retrospective. The whole team participates in this meeting, including
the ScrumMaster and product owner. The meeting is an opportunity to
reflect on the sprint that is ending and identify opportunities to
improve in the new sprint.

What are the main artifacts of a Scrum project?

The primary artifact of a Scrum project is, of course, the product itself.
The team is expected to bring the product or system to a potentially
shippable state at the end of each sprint.
The product backlog is a complete list of the functionality that remains
to be added to the product. The product backlog is prioritized by the
product owner so that the team always works on the most valuable
features first. The most popular and successful way to create a product
backlog is to populate it with user stories, which are short descriptions
of functionality described from the perspective of a user or customer.
On the first day of a sprint and during the sprint planning meeting,
team members create the sprint backlog. The sprint backlog can be
thought of as the teams to-do list for the sprint. Whereas a product
backlog is a list of features to be built (often written in the form of user
stories), the sprint backlog is the list of tasks the team needs to

Scrum

Page 2 of 20

perform in order to deliver the functionality they committed to deliver

during the sprint.
Two other primary artifacts are the sprint burndown chart and release
burndown chart. Burndown charts show the amount of work remaining
either in a sprint or a release. They are a very effective tool for
determining at a glance whether a sprint or release is on schedule to
have all planned work finished by the desired date.

What are the main roles on a Scrum team?

Even if you are new to Scrum, you may have heard of a role called
ScrumMaster. The ScrumMaster is the teams coach and helps team
members achieve their highest level of performance. A ScrumMaster
differs from a traditional project manager in many key ways, including
that the ScrumMaster does not provide day-to-day direction to the
team and does not assign tasks to individuals. A good ScrumMaster
shelters the team from outside distractions, allowing team members to
focus maniacally during the sprint on the goal they have selected.
While the ScrumMaster focuses on helping the team be the best that it
can be, the product owner works to direct the team at the right goal.
The product owner does this by creating a compelling vision of the
product and then conveying that vision to the team through the
product backlog.
The product owner is responsible for ensuring that the product backlog
remains prioritized as more is learned about the system being built, its
users, the team, and so on.
The third and final role on a Scrum project is the team itself. Although
individuals on a Scrum team may come to that team with various job
titles, while on the team those titles are insignificant. Each person
contributes in whatever ways they best can to complete the work of
each sprint. This does not mean that a tester will be expected to rearchitect the system; individuals will spend most (and sometimes all)
of their time working in whatever discipline they worked before
adopting Scrum. But on a Scrum team, individuals are expected to
work beyond their preferred disciplines whenever doing so would be for
the good of the team.
One convenient way to think of the interlocking nature of these three
roles is as a race car. The team is the car itself, ready to speed along in
whatever direction it is pointed. The product owner is the driver,
making sure that the car is always going in the right direction. The
ScrumMaster is the chief mechanic, keeping the car well-tuned and
performing at its best.

Scrum

Page 3 of 20

Scrum

Page 4 of 20

Where can I learn more?

We have prepared a complete set of pages on this site that will give
you a solid introduction to the essentials of Scrum. You can learn about
the following topics:
o
o
o
o
o
o
o
o
o
o
o
o
o

Overview of Scrum
Daily scrum
Product backlog
Product owner
Release burndown
ScrumMaster
Scrum team
Sprint backlog
Sprint planning meeting
Sprint review meeting
Using a task board
Scrum illustrations and wallpapers
A Presentation on Scrum

If after reading a bit about Scrum, you decide youd like to take the
next step, consider attending Certified ScrumMaster class or
scheduling one for your company.

An Overview of Scrum for Agile Software Development

As a brief introduction, Scrum is an agile process for software development.
With Scrum, projects progress via a series of iterations called sprints. Each
sprint is typically 2-4 weeks long. Scrum is ideally suited for projects with
rapidly changing or highly emergent requirements.
A scrum team is typically made up of between five and nine people, but
Scrum projects can easily scale into the hundreds. The team does not
include any of the traditional software engineering roles such as
programmer, designer, tester, or architect. Everyone on the project
works together to complete the set of work they have collectively
committed to complete within a sprint. Scrum teams develop a deep
form of camaraderie and a feeling that were all in this together.

The product owner is the projects key stakeholder and represents users,
customers and others in the process. The product owner is often

Scrum

Page 5 of 20

someone from product management or marketing, a key stakeholder

or a key user.
The ScrumMaster is responsible for making sure the team is as productive as
possible. The ScrumMaster does this by helping the team use the
Scrum process, by removing impediments to progress, by protecting
the team from outside, and so on.
The product backlog is a prioritized features list containing every desired
feature or change to the product.
At the start of each sprint, a sprint planning meeting is held during which the
product owner prioritizes the product backlog, and the scrum team
selects the work they can complete during the coming sprint. That
work is then moved from the product backlog to the sprint backlog,
which is the list of tasks needed to complete the product backlog items
the team has committed to complete in the sprint.
Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each days work and
helps the team stay on track. All team members are required to attend
the daily scrum.

At the end of each sprint, the team demonstrates the completed functionality
at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a
demonstration of the new features, but in an informal way; for
example, PowerPoint slides are not allowed. The meeting must not
become a task in itself nor a distraction from the process.
Note :
The term backlog can get confusing because its used for two different
things. To clarify: the product backlog is a list of desired features for the
product. The sprint backlog is a list of tasks to be completed in a
sprint.

A Visual Introduction to Scrum Graphically, Scrum looks something like this:

Scrum

Page 6 of 20

This graphic is an introduction to everything essential in Scrum agile software

development. On the left, we see the product backlog, which has been
prioritized by the product owner and contains everything wanted in the
product thats known at the time. The 2-4 week sprints are shown by
the larger green circle.
At the start of each sprint, the team selects some amount of work from the
product backlog and commits to completing that work during the
sprint. Part of figuring out how much they can commit to is creating the
sprint backlog, which is the list of tasks (and an estimate of how long
each will take) needed to deliver the selected set of product backlog
items to be completed in the sprint.
At the end of each sprint, the team produces a potentially shippable product
increment i.e. working, high-quality software. Each day during the
sprint, team members meet to discuss their progress and any
impediments to completing the work for that sprint. This is known as
the daily scrum, and is shown as the smaller green circle above.

The Daily Scrum Meeting

On each day of a sprint, the team holds daily meetings (the daily scrum).
Meetings are typically held in the same location and at the same time
each day. Ideally the daily scrums are held in the morning as they help
set the context for the coming day's work.
There is an old joke in which a chicken and a pig are talking and the chicken
says, "Let's start a restaurant." The pig replies, "Good idea, but what
should we call it?" "How about 'Ham and Eggs'" says the chicken. "No

Scrum

Page 7 of 20

thanks," says the pig, "I'd be committed, you'd only be involved." The
joke is meant to point out the difference between those who are
committed on a project and those who are only involved. Scrum affords
special status to those who are committed and many teams enforce a
rule in which only those who are committed are allowed to talk during
the daily scrum.
All team members are required to attend the daily scrum. Since both the
ScrumMaster and Product Owner are committed team members, they
are expected to attend and participate. Anyone else (for example, a
departmental VP, a salesperson, or a developer from another project)
is allowed to attend but is there only to listen. This makes the daily
scrums an excellent way for a Scrum team to disseminate status
information--if you're interested in hearing where things are at, attend
that day's meeting.
The daily scrum is not used as a problem-solving or issue resolution meeting.
Issues that are raised are taken offline and usually dealt with by the
relevant sub-group immediately after the daily scrum. During the daily
scrum each team member provides answers to the following three
questions:
What did you do yesterday?
What will you do today?
Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish
today the team gains an excellent understanding of what work has
been done and what work remains. The daily scrum is not a status
update meeting in which a boss is collecting information about who is
behind schedule. Rather, it is a meeting in which team members make
commitments to each other. If a programmer stands up and says
"Today I will finish the data storage module" everyone knows that in
tomorrow's meeting he will say whether or not he did finish. This has
the wonderful effect of helping a team realize the significance of these
commitments and that their commitments are to each other, not to
some far-off customer or salesman.
Any impediments that are raised become the ScrumMaster's responsibility to
resolve as quickly as possible. Typical impediments are:

My ____ broke and I need a new one today.

I still haven't got the software I ordered a month ago.

Scrum

Page 8 of 20

I need help debugging a problem with ______.

I'm struggling to learn ______ and would like to pair with someone on it.
I can't get the vendor's tech support group to call me back.
Our new contractor can't start because no one is here to sign her contract.
I can't get the ____ group to give me any time and I need to meet with them.
The department VP has asked me to work on something else "for a day or
two."
In cases where the ScrumMaster cannot remove these impediments directly
himself (e.g., usually the more technical issues) he still takes
responsibility for making sure someone on the team does quickly
resolve the issue.

Learning Scrum - The Product Backlog

The Product Backlog is the master list of all functionality desired in the
product. When using Scrum, it is not necessary to start a project with a
lengthy, upfront effort to document all requirements. Typically, a Scrum team
and its product owner begin by writing down everything they can think of
easily. This is almost always more than enough for a first sprint. The Product
Backlog is then allowed to grow and change as more is learned about the
product and its customers.
Product backlog items can be technical tasks ("Refactor the Login class to
throw an exception") or more user-centric ("Allow undo on the setup screen").
My preference is to express the product backlog in the form of user stories,
which are a technique borrowed from Extreme Programming, another agile
process.
The product owner shows up at the sprint planning meeting with the
prioritized product backlog and describes the top items to the team. The
team then determines which items they can complete during the coming
sprint. The team then moves items from the Product Backlog to the Sprint
Backlog. In doing they expand each Product Backlog item into one or more
Sprint Backlog tasks so they can more effectively share work during the
Sprint. Conceptually, the team starts at the top of the prioritized Product
Backlog list and draws a line after the lowest of the high priority items they
feel they can complete. In practice it is not unusual to see a team select, for
example, the top five items and then two items from lower on the list but that
are associated with the initial five.

Scrum

Page 9 of 20

An example Product Backlog from a real project appears as the following:

This Excel spreadsheet shows each product backlog item assigned a general
priority (Very High, High, etc.) by the Product Owner. Estimates have been
developed by the developers but it is understood that they are very imprecise
and are useful only for rough assignments of tasks into the various sprints.

Learning Scrum - The Product Owner

The Product Owner (typically someone from a Marketing role or a key user in
internal development) prioritizes the Product Backlog.
The Scrum Team looks at the prioritized Product Backlog and slices off the top
priority items and commits to completing them during a sprint. These items
become the Sprint Backlog.
In return for their commitment to completing the selected tasks (which, by
definition, are the most important to the product owner), the product owner

Scrum

Page 10 of 20

commits that he or she will not throw new requirements at the team during
the sprint. Requirements are allowed to change (and change is encouraged)
but only outside the sprint. Once the team starts on a sprint it remains
maniacally focused on the goal of that sprint.

Release Burndown Charts - Agile Scrum Release Burndown Charts for Scrum
& agile projects
Release Burndown
On a Scrum project, the team tracks its progress against a release plan by
updating a release burndown chart at the end of each sprint. The horizontal
axis of the release burndown chart shows the sprints; the vertical axis shows
the amount of work remaining at the start of each sprint. Work remaining can
be shown in whatever unit the team prefers--story points, ideal days, team
days, and so on. My preference is for story points, for all of the reasons
described in the Agile Estimating and Planning book.

On this burndown chart, the team started a project that was planned to be
eleven two-week sprints. They began with 200 story points of work. The first
sprint went well and from the chart you can infer that they had around 180
story points of work remaining after the first sprint. During the second sprint,
however, the estimated work remaining actually burned up. This could have
been because work was added to the project or because the team changed
some estimates of the remaining work. From there the project continued well.
Progress slowed during sprint 7 but then quickly resumed.

Scrum

Page 11 of 20

This type of release burndown chart works very well in many situations and in
many teams. However, on projects with lots of changing requirements you
may want to look at an alternative release burndown chart.

Learning Scrum - The ScrumMaster

ScrumMaster
The ScrumMaster is responsible for making sure a Scrum team lives by the
values and practices of Scrum. The ScrumMaster protects the team by
making sure they do not over-commit themselves to what they can achieve
during a sprint.
The ScrumMaster facilitates the daily scrum and becomes responsible for
removing any obstacles that are brought up by the team during those
meetings.
The ScrumMaster role is typically filled by a project manager or a technical
team leader but can be anyone.

Scrum Team Training

The Scrum Team
Scrum teams do not include any of the traditional software engineering roles
such as programmer, designer, tester, or architect. Everyone on the project
works together to complete the set of work they have collectively committed
to complete within a sprint. Scrum teams develop a deep form of
camaraderie and a feeling that "we're all in this together."
A typical Scrum team is 5-9 people. Rather than scaling by having a large
team, Scrum projects scale through having teams of teams. In this way I have
worked on projects with over 500 people and have consulted to projects with
over 1,000.
Although not the only thing necessary to scale Scrum, one well-known
technique is the use of a "Scrum of Scrums" meeting. With this approach
each Scrum team proceeds as normal but each team identifies one person
who attends Scrum of Scrum meetings to coordinate the work of multiple

Scrum

Page 12 of 20

Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but
do not necessarily happen every day. In many organizations, having a Scrum
of Scrums meeting two or three times a week is sufficient.
The illustration below shows how a Scrum of Scrums approach allows Scrum
to scale up (in this case to 243 people). Each cell represents one person on a
Scrum team. The bottom of this illustration shows teams with nine developers
on them. One person from each team (the differently colored cell) also
participates in a Scrum of Scrum to coordinate work above that team. Then
from those nine-person teams another person is selected (this time shown
with diagonal lines) to participate in what is called a Scrum of Scrums of
Scrums.

You can also read further for advice on conducting the Scrum of Scrums
meeting.

Scrum Training on Sprint Backlog

Sprint Backlog
The sprint backlog is the list of tasks that the Scrum team is committing that
they will complete in the current sprint. Items on the sprint backlog are drawn
from the Product Backlog, by the team based on the priorities set by the
Product Owner and the team's perception of the time it will take to complete
the various features.
It is critical that the team selects the items and size of the sprint backlog.
Because they are the ones committing to completing the tasks they must be
the ones to choose what they are committing to.

Scrum

Page 13 of 20

The sprint backlog is very commonly maintained as an Excel spreadsheet but

it is also possible to use your defect tracking system or any of a number of
software products designed specifically for Scrum or agile. An example of the
Sprint Backlog in Excel looks like this:

During the Sprint the ScrumMaster maintains the sprint backlog by updating
it to reflect which tasks are completed and how long the team thinks it will
take to complete those that are not yet done. The estimated work remaining
in the sprint is calculated daily and graphed, resulting in a sprint burndown
chart like this one:

The team does its best to pull the right amount of work into the sprint but
sometimes too much or too little work is pulled in during the Sprint planning
meeting. In this case the team needs to add or remove tasks. In the above
sprint burndown chart you can see that the team had pulled in too much
work initially and still had nearly 600 hours to go on 5/16/02. In this case the
Product Owner was consulted and it was agreed to remove some work from
the sprint, which resulted in the big drop on the chart between 5/16/02 (619

Scrum

Page 14 of 20

hours) and 5/17/02. From there the team made good consistent progress and
finished the sprint successfully.

Agile Training on Sprint Planning Meeting

Sprint Planning Meeting

The Sprint Planning Meeting is attended by the Product Owner, Scrum Master,
the entire Scrum Team, and any interested and appropriate management or
customer representatives.
During the sprint planning meeting the product owner describes the highest
priority features to the team. The team asks enough questions during this
meeting so that they can go off after the meeting and determine which tasks
they will move from the product backlog to the sprint backlog.
The product owner doesn't have to describe every item being tracked on the
product backlog. Depending on the size of the backlog and the speed of the
team it may be sufficient to describe only the high priority items, saving the
discussion of lower priority items for the next sprint planning meeting.
Typically, the Scrum team will provide guidance when they start to get further
into the backlog list than they know could be done in the next sprint.
Collectively, the Scrum team and the product owner define a sprint goal,
which is a short description of what the sprint will attempt to achieve. The
success of the sprint will later be assessed during the Sprint Review Meeting
against the sprint goal, rather than against each specific item selected from
the product backlog.
After the sprint planning meeting, the Scrum team meets separately to
discuss what they heard and decide how much they can commit to during the
coming sprint. In some cases there will be negotiation with the product owner
but it will always be up to the team to determine how much they can commit
to completing.

Scrum

Page 15 of 20

Sprint Review Meeting

At the end of each sprint a sprint review meeting is held. During this meeting
the Scrum team shows what they accomplished during the sprint. Typically
this takes the form of a demo of the new features.
The sprint review meeting is intentionally kept very informal, typically with
rules forbidding the use of PowerPoint slides and allowing no more than two
hours of preparation time for the meeting. A sprint review meeting should not
become a distraction or significant detour for the team; rather, it should be a
natural result of the sprint.
Participants in a Sprint Review
Participants in the sprint review typically include the Product Owner, the
Scrum team, the ScrumMaster, management, customers, and developers
from other projects.
Purpose of a Sprint Review
During the sprint review the project is assessed against the sprint goal
determined during the Sprint planning meeting. Ideally the team has
completed each product backlog item brought into the sprint, but it is more
important that they achieve the overall goal of the sprint.

Training for Scrum Task Board Use

Task Boards
Ive written in a couple of places about how I like to use a task board during
Scrum sprints (iterations). The task board shows all the work were doing
during a sprint. We update it continuously throughout the sprintif someone
thinks of a new task (Test the snark code on Solaris 8) she writes a new
card and puts it on the wall. Either during or before the daily scrum,
estimates are changed (up or down) and cards are moved around the board.
Generically, the task board looks like this:

Scrum

Page 16 of 20

A generic task board. Click to enlarge.

Each row on the task board is a user story, which is the unit of work I
encourage teams to use for their product backlog. During the sprint planning
meeting the team selects the product backlog items they can complete
during the coming sprint. Each product backlog item is turned into multiple
sprint backlog items. Each of these is represented by one task card that is
placed on the task board. Each task card starts on the task board in the To
Do column. The columns I always use on a task board are:

StoryThe story description (As a user I want to) shown on that row.
To DoThis holds all the cards that are not done or in process.
Work In ProcessAny card being worked on goes here. The programmer
who chooses to work on it moves it over when shes ready to start the
task. Often this happens during the Daily Scrum when someone says,
Im going to work on the boojum today.
To VerifyA lot of tasks have corresponding test task cards. So, if
theres a Code the boojum class card there is likely one or more task
cards related to testing: Test the boojum, Write FitNesse tests for
the boojum, Write FitNesse fixture for the boojum, etc. Some task
cards dont often get corresponding test cards (Fix Bug #321 in
Bugzilla) so those are placed in the To Verify column.
DoneCards pile up over here when theyre done. Theyre removed at
the end of the sprint. Sometimes I remove some or all during a sprint if
there are a lot of cards.

Optionally, I sometimes use the following columns depending on the team,

the culture, the project, and other considerations:

NotesJust a place to jot a note or two

Tests SpecifiedI like to do Story Test-Driven Development, which
means the tests are written before the story is coded. Im not a stickler
about it but it does help when theres time to specify the tests (at a
high level) in advance. This column just contains a checkmark to

Scrum

Page 17 of 20

indicate the tests are specified. Ideally, not a lot of work (in the form of
task cards) crosses this column without a checkmark in it.
Here are some photos of actual task boards in use. Click on any to enlarge.

A task board hanging in a team room.

Cork board hung on the wall.

Scrum

Page 18 of 20

A metal task board with cards placed with magnets.

A task board made with black tape on a large wall-sized cabinet. There's food
in the cabinet!

Scrum

Page 19 of 20

A distributed team using Outlook's notes facility on a shared desktop.

Scrum

Page 20 of 20