Why Scrum Works

Why does Scrum work? Why do any of the Agile methodologies work? How does Scrum help
teams deliver value? How does it help high performance teams form?

This series of posts that will look at why Scrum works on three levels:

Scrum delivers value to the business

Scrum helps form high performing teams
Scrum helps motivate and focus team members

Delivering value to the business

Scrum delivers value to the business through:

Every iteration the product is ready to ship.

Adapt to changing requirements: Short iterations mean that the Product Owner provides
frequent feedback. As result there are frequent small course corrections as opposed to
massive changes late in the project.

Visibility of progress: delivering a working product at the end of every iteration means
that the customer, executive sponsors and other interested parties can see the product take
shape. They are not surprised six weeks before release.

Accurate tracking of how much work is left before release: the combination of the
product backlog and the team's velocity (aka Yesterday's weather in XP speak) means
that you tell how much the team will get done by the release date.

Lightweight requirements: Since the team is in frequent (preferably daily contact) with
the Product Owner, she spends less time writing detailed requirements. Instead she is able
focus on making decisions and answering questions from developers.
 Process improvement mechanism to meet business needs: As business needs change
SOX, FDA compliance, through the retrospective the Scrum process can be improved
and adapted to meet goals and needs in changing environments.

In short, Scrum provides a way for the business to maximize its ROI by using iterative
development to rapidly create working software. It ensures that the team is always working to
deliver the highest priority features.
Scrum is an agile process to manage software development projects. Scrum is not prescriptive on
engineering practices, but rather it is a lightweight framework based on a few (common sense)
guidelines for managing projects. Scrum follows an empirical process control in which the team adapts
based on experience rather than following a rigorous set of steps or a very detailed plan. The word
Scrum itself comes from rugby and refers to a way of restarting the game.

This article presents an overview of the different roles that each team member plays in Scrum, the life
cycle of projects managed with Scrum, a description of Scrum's key practices, why they work, and some
practical advice on how to implement them.

Scrum as we know it today is the result of the work and collaboration of Jeff Sutherland and Ken
Schwaber, circa 1995. In 2001 Ken Schwaber and Mike Beedle wrote the book Agile Software
Development with Scrum, which helped the practices reach a broader audience and become a
mainstream software development process.

Most Scrum team members are found in traditional development teams. Yet there are subtle
differences in their responsibilities when working in a Scrum team that are worth discussing first.

The Scrum Team

There are three main roles in a Scrum team: ScrumMaster, Product Owner, and Development Team.

ScrumMaster
The ScrumMaster role is somewhat similar to a project manager in traditional software development;
however, the creators of Scrum gave it a different name to emphasize the different nature of this role.
Although the ScrumMaster is responsible for making sure the team is moving as quickly as possible, the
role is more of a facilitator and coach than of exercising control and making decisions. The ScrumMaster
helps the team follow the Scrum principles (such as making sure iterations are time-boxed, removing
roadblocks, fostering collaboration among team members, and so on). Unlike traditional project
manager roles, the ScrumMaster does not assign individual tasks to the developers or QA. Instead, the
development team self-organizes on each iteration and determines who performs each task. The
ScrumMaster must be available at all times to remove roadblocks and ensure that the team has all
required resources for the job.

Product Owner
The Product Owner is a representative from the business side who determines the priorities of the items
to be developed. The Product Owner must be either on-site or available to the team at all times to
answer questions and clarify unclear requirements. For example, the product owner should reply to e-
mails and return phone calls promptly, and attend demos of the work in progress to verify that the team
is moving in the right direction. Unlike other development processes, the Scrum Product Owner is
actively involved in the project throughout its duration, not just at the beginning or at the end.

Development Team
The Development Team in Scrum can be composed of developers, QA, and business analysts. The
development team provides estimates and does the work. However, the development team does not
select what features should be developedthat's the Product Owner's job. Once an iteration starts, the
development team self-organizes and decides who will do each item and what is the best way to
approach it. During each iteration, developers, QA, and business analysts work very closely on a daily
basis to make sure the work is properly designed, coded, tested, fixed, and potentially shippable at the
end of the iteration.

Team collaboration and self-organization are key practices in Scrum teams, because they allow the
people doing the work to decide on the best approach for getting the job done and carrying it out. It is
amazing how much productivity improves when members of a cross-functional team collaborate with
each other on a daily basis. This synergy between team members in a Scrum team is one of the greatest
benefits of Scrumand in my experience, accounts for a large portion of the success of Scrum teams.

Process Overview
Scrum projects are managed in short iterations (Sprints) where the team works on the most
important items of the project, as defined by the Product Owner, and delivers potentially
shippable code at the end of each iteration. Everything in Scrum revolves around Sprints. Figure
1 shows the basic skeleton of the Scrum process, including key components such as the Product
Backlog, the Sprint Backlog, the Sprint, and the Daily Meeting. The following sections
chronologically describe what happens in the life cycle of a project using Scrum. Table 1 shows
a summary of these steps along with the goals and responsibilities of everyone involved.

Figure 1. Scrum Process Overview: Here's

the basic Scrum process skeleton, showing
the key components.

Table 1. Scrum Process: Here are the major checkpoints for a team using Scrum.
Step Duration Participants Goal
Sprint planning 4-8 hours Entire team (Product Select from Product Backlog features to
meeting Owner, ScrumMaster, develop in the next Sprint. The result is
business analysts, called the Sprint Backlog. Come up with an
developers, QA) initial plan to carry out the Sprint Backlog.
Sprint 2 weeks Entire team Team works on Sprint Backlog. Result is
potentially shippable software.
 (or 30 days)
Daily meeting 15 minutes Entire team Team members synch up with each other,
review progress of the Sprint, and identify
(every day for the roadblocks.
duration of the
Sprint)

Sprint 1 hour Entire team Team members debrief how things went in
retrospective the Sprint and discuss potential
meeting improvements for future Sprints.

Sprint Planning
Before a Sprint starts, the Product Owner (with the help of the ScrumMaster) reviews the list of
all new features, enhancements, change requests, and any bug reports accumulated over time to
decide which ones are most immediately important. If this is a new project, the list includes the
features that the new system must provide. The entire list of items is called the "Product
Backlog," and each item must include a description of what is requested, the priority for the
business, and ballpark estimates for completing the item. It's the Product Owner's job to make
sure this list is always up to date.

Scrum gives the Product Owner a large degree of control during the life of a project, letting the
owner change priorities at every planning meeting (every two weeks or every 30 days depending
on the size of your Sprint).

Because Product Owners represent the business, they typically have

an idea of what customers want and what needs to be delivered first. Scrum's practices and
guidelines work
Armed with this knowledge and preliminary estimates, the Product because they address
Owner selects a subset of items from the Product Backlog for the most important
consideration in the Sprint planning meeting. component of software
development: people
The Sprint planning meeting has two parts. During the first half of and their interactions.
the meeting (the first 2-4 hours) the Product Owner describes the
features to the Scrum team to be implemented during the next iteration. Developers and QA ask
questions to the Product Owner to come up with "good enough" estimates for each item. This is
not a design meeting. The fact that this is a short meeting forces the team not to spend too much
time overanalyzing each item. The ScrumMaster helps to keep this meeting focused and within
the agreed-upon time.

Once estimates have been provided by the team, if there is more work estimated than time
available in the Sprint, it is the job of the Product Owner to decide which Product Backlog items
will be removed from the Sprint and which ones will be kept. It is very important to keep no
more items than developers believe they can complete. It is also important to let the Product
Owner (and not the developers) decide which items should be kept on the Sprint. In short: the
development team estimates, but the Product Owner prioritizes.
As tempting as it might be to extend the duration of a Sprint "just a few more days" to make
room for and squeeze in a few more items, Scrum practitioners recommend that you keep the
Sprint size fixed, a process called "time boxing." Time boxing forces the Product Owner to make
choices and focus on high priority items rather than trying to include every possible feature in
one iteration. The ScrumMaster enforces this practice during the planning meeting. Remember
that Scrum is iterative; there will be more iterations. If the items left out are still very important,
they will come to the top of the list in the next Sprint planning meeting.

Items kept on the Sprint are called the Sprint Backlog. These items will be the focus of the team
for the duration of the Sprint. During the second half of the Sprint planning meeting (the last 2-4
hours) the team comes up with a plan to carry out the items in the Sprint Backlog. For example,
the team might break down some of the items into smaller blocks, so that multiple developers
can work on an item, decide how the features are going to be tested, what features depend on
each other, and which ones should be handled first on the Sprint.

The Sprint
A Sprint is an iteration in which the development team (developers and QA) works on the Sprint
Backlog. During this time, the Product Owner must be available to answer questions and provide
feedback on features as they evolve. At the end of the Sprint, the development team has the
responsibility of providing potentially shippable code. Potentially shippable code means code
that has been written, tested, and is ready to go to production, even if it will not go to production
immediately. Scrum recommends that the team gives a demonstration to the Product Owner of
the software with the new features at the end of the Sprint.
A Sprint typically lasts either 2 weeks or 30 days. Early literature about Scrum recommended 30
days but most teams do 2-week Sprints lately. I prefer two-week Sprints for various reasons.
First, it's easier for the team to plan, estimate, and complete two weeks of work than four or six.
A shorter time period also shortens Sprint planning meetings and tends to make estimates more
accurate. Two-week Sprints also allow the Product Owner freedom to change priorities more
often, which helps the team adapt to market pressures quickly.

Whatever time frame you chose for your Sprints, make sure they are time boxed. Time boxing
gives the team a tangible goal (for example, at the end of two weeks you'll have these four new
features completed.) People work better when they know they can succeed and when there is an
end in sight. Forcing teams to have potentially shippable code at the end of every Sprint also
prevents teams from going into a perennial "85% done" state where the team is always very close
to completing a taskbut it never gets done. Time boxing also encourages the team to keep the
system stable since they know there is a checkpoint at the end of the Sprint in which they will
need to demonstrate a working, potentially shippable version of the system. This is good for the
development team, the Product Owner, and the customers.

Keeping the duration of the Sprint constant for the entire project is also a good practice because
it provides rhythm to the team.

Product Owners cannot add more work to a Sprint once it gets started. They must delay new
requirements until the next Sprint planning meeting. However, because Sprints are usually short,
and include what the Product Owner thought was most important, Product Owners are typically
receptive to the idea of waiting until the Sprint ends to change priorities. Remember that they can
reprioritize on each Sprint planning meeting. It is possible to stop and cancel a Sprint in progress
if the Product Owner cannot wait, and priorities must be changed in the middle of the Sprint. In
my experience this happens rather infrequently in Scrum.

Scrum is also different from other software development processes in that neither the
ScrumMaster nor the Product Owner assigns specific tasks to the development team. In Scrum
teams, after the Sprint Backlog has been defined, the team members decide among themselves
how to accomplish it. Some teams prefer to pre-allocate all items among themselves during the
planning meeting, while others allocate only a handful of items, and members pick up the
remaining items as they complete the first ones.

The ScrumMaster's main job during the Sprint is to make sure the team's needs are met, and to
remove roadblocks. This includes ensuring that developers and QA have access to all necessary
resources (people, documents, hardware, software). They also facilitate meetings with external
parties, reduce distractions (such as people working on things not part of the Sprint Backlog),
and coach the Product Owner and development team when decisions must be made. All in all,
they make sure that developers and QA are working in the best possible environment.

The Product Owner needs to be easily accessible during the Sprint to answer questions about
Sprint Backlog items, review work in progress with the development team, and make sure
features are moving in the right direction.

For the duration of the Sprint, developers and QA work with each other on a daily basis. In some
teams, QA works side-by-side with developers to design, develop, and test features, while in
others they test features within a few hours of development (not weeks later). This tight loop
between developers and QA is critical to ensure potentially shippable code at the end of the
Sprint. Code that was written but not tested is very unlikely to be potentially ready to be shipped
to production.

Daily Meeting
During the Sprint, team members get together on a daily basis to report their status to the team.
The Scrum daily meetingor daily scrumis a short meeting time boxed at 15 minutes in
which each participant answers three questions:

What did you do since the last daily meeting?

What will you do from now until the next daily meeting?
Are there any roadblocks in your way?

Although the entire team is present at the daily meeting, it is very important to notice that the
daily meeting is for team members to report status to their peers, not to the ScrumMaster or the
Product Owner. This meeting keeps the pace of the team visible on a daily basis to everybody
involved on the team. If the team is moving along as planned it will be evident during these
meetings. Likewise, if someone is having difficulties it will not go unnoticed. Frequent peer
reporting helps teams self-organize efficiently as the Sprint progresses, and provides
accountability among team members. It is important for the Product Owner and the ScrumMaster
to be present in this meeting to detect roadblocks and act on them as soon as possible.

As an example, during a typical daily meeting one developer might report that yesterday he
completed the middle-tier component for a particular module, and today he plans to wrap up the
web page that will use it. He will inform the Product Owner and QA that they should be able to
take a look at it the next day. Another developer might report that she is having trouble finding
the root of a problem in the login process, and could use some help. QA might report that the
contacts screen seems to be broken as a result of a fix in another module, and that the developers
need to fix that before they can continue testing other screens on the same module.

To keep the meeting short, discussions that only involve one or two team members, or that might
take more than a few minutes need to be scheduled outside the daily scrum. It is common for the
daily meeting to be a stand-up meeting. This helps to keep the meeting short since people usually
do not like to stand for more than 15 minutes.

Sprint Retrospectives
Scrum is an adaptive process. One way Scrum teams achieve this is by conducting regular
retrospective meetings to talk about what was successful in the last Sprint, what could be
improved in the next one, and new ways in which the team could get better. These are candid
meetings in which the whole team (Product Owner, ScrumMaster, developers, and QA)
participates.

Ideally, the team will hold these meetings at the end of each Sprint. Retrospective meetings
provide a forum for the team to voice concerns and boast about things that went well. It is very
important to balance the meeting with successes and areas for improvement. To achieve this
balance you can request that every participant brings to the meeting a list of two or three
practices that helped the team perform well and two or three areas where the team needs to
improve.

Retrospective meetings can be hard to manage because they can easily turn into emotional
discussions. To prevent this, it is very important to keep the meeting focused on how to work
better as a team and not into a forum for personal attacks. I have found retrospective meetings to
be of great value to let teams vent things that frustrate them and get ideas from the whole team
on how to address these issues. Likewise, when things are going well, it is good for the team to
talk about what makes them successful, and to make sure everybody is aware of what the team
needs to maintain to keep the momentum going. These meetings also enforce the concept that
everybody involved (ScrumMaster, Product Owner, developers, QA) works together as a single
team, and that they need to collaborate with each other.

At a retrospective meeting, teams might discuss things such as, "We need to make sure our unit
tests are kept up to date, because when we ignored them during the last Sprint, issues crept up
beyond our control." or "I found it really helpful to demo the new screens to Jane early on, rather
than at the end of the Sprint." or "We need better communication between developers and QA; a
lot of bugs didn't get tested early on because the developers didn't flag them as ready to be tested
on time."

It is important to follow up on what the team agrees to during these meetings. If the team decided
it should start doing something new, such as demoing work in progress to the Product Owner
sooner, the ScrumMaster needs to help the team to make sure the demos are being conducted
earlier. The ScrumMaster also needs to bring this topic back to the next retrospective meeting to
see if the team feels they are moving in the right direction.

After the retrospective meeting the team is ready for a new Sprint. The team gets together for a
new Sprint planning meeting and then repeats the cycle. Since the code is potentially shippable at
the end of every Sprint, the regression testing process is considerably simplified. Some teams
have a special type of Sprint called Release Sprint in which all they do is deploy the system to
the testing environment, conduct regression testing, fix any issues found during this process, and
then promote to production the features completed in the Sprints since the last release.

Why Scrum Works

Scrum's practices and guidelines work because they address the most important component of
software development: people and their interactions. Scrum provides a framework for the entire
team (Product Owner, ScrumMaster, developers, quality assurance, and business analysts) to
collaborate, and work with each other on a regular basis.

For example, the daily meeting helps the entire team (not only the ScrumMaster or the Product
Owner) monitor progress on a daily basis. If the team starts falling behind, it can adapt and self-
reorganize immediately. Time boxing in the Sprint helps the Product Owner monitor progress at
specific intervals, because at the end of the iteration, the features planned during the planning
meeting are either potentially shippable or not. The goal of potentially shippable code guides
everybody in the team to work towards the same goal. The Sprint retrospective meeting allows
the team to reflect on successes, talk about areas for improvement, and to take measurements to
improve in the next Sprint.

A common misunderstanding is to see the Scrum process as a mini-waterfall. Just having short
iterations is not enough to make Scrum work. For Scrum to shine it is vital that all team members
work together on the same goal during the Sprint. If developers are coding a set of features but
QA is testing a different set of features they are not working together. You are not going to have
potentially shippable code at the end of this Sprint. The ScrumMaster must promote this
collaboration model, especially on teams that have never worked as close together as Scrum
suggests.

Scrum fosters an environment in which teams can succeed in the long term by maintaining a
constant pace. Using short iterations and self-inspection every step of the process (e.g. daily
meetings, Sprints, and retrospectives) allows Scrum teams to always know the status of the
project and to make sure the team is moving towards the same goal. Since Sprints are short in
duration and the team is always focused on having potentially shippable code at the end of the
iteration, Scrum prevents the so-called "student syndrome" in which people apply themselves
only at the last moment before a deadline. Figure 2 shows the stress level on teams that do not
have short iterations and regular checkpoints. These teams are often relaxed at the beginning and
stressed out towards the end of the project. Scrum's short iterations and regular checkpoints lead
teams to a more efficient model in which team members themselves detect deviations, and make
adjustments early on rather than wait until it is too late. The stress level on Scrum teams tends to
be low, like the one depicted in Figure 3.

Figure 2. Traditional Process: Figure 3. Scrum Process: The stress

Here's an analysis of stress levels in level in Scrum teams is typically
traditional software processes teams. low.
Progress Tracking
Scrum teams have several ways to track project status. One is that at the end of the Sprint, the
team must have potentially shippable code. Having teams give demonstrations to the Product
Owner of the new features at the end of each Sprint is a great way to encourage this goal. At the
end of the Sprint, the software is potentially ready to be shipped or not. This kind of binary
status, common in agile development processes, tends to be more meaningful to Product Owners
than the perennial "we are 85% complete."

Another way Scrum teams can measure progress is with

burndown charts. These are charts in which the amount of work
left to be done in a Sprint is updated on a daily basis and made
available to the entire team. If at the beginning of the Sprint there
are 200 hours of work to be done, on day 2 the chart is updated to
indicate how much work (as estimated by the developers working Figure 4. Ideal Sprint
on each task) is still left. Burndown Chart: In an
ideal Sprint, the burndown
As tasks are completedcoded and testedthe number of hours chart shows steady progress.
left to be done decreases. When no tasks are completed, the
number of hours left to be done stays the same from one day to another. Figure 4 shows an
example of a Sprint burndown chart in which everything went perfectly. Every day of the Sprint
the team completed 20 hours and finished everything on time.
On the other hand, Figure 5 shows an example in which the team
ran into some difficulties on day 3 (the number of hours left
remained almost the same as the day before) and these difficulties
continued on days 4 and 5. Perhaps some of the items were
harder to implement than the team had anticipated, or a teammate
got sick. Figure 5. Troubled
Burndown Chart: This
Whatever the reason for the slowdown, by day 6 the team had Sprint burndown chart shows
taken some corrective actions (for example, removed a few items a Sprint where things did not
from the Sprint after talking to the Product Owner) so they could go as planned.
provide potentially shippable code on the items still achievable
by the end of the Sprint.

Scrum is not a silver bullet. Even when using Scrum it is still possible (and likely) that things
will go differently from what was planned every now and then. However, with frequent
inspection and adaptation, the team detects these variations as soon as they happen, and adapts to
its new environment. This ability to quickly adapt to a new environment is one of the key
differences between empirical process controls (like Scrum) and defined process controls like the
one used by traditional non-agile software development processes.

Perhaps the best tracking mechanism that takes place in Scrum teams is the constant feedback
loop that Scrum provides. By having the entire team (Product Owner, developers, quality
assurance, and ScrumMaster) collaborating throughout the duration of the Sprint, teams tend to
know more about where they are, notice if they are falling behind, and act to solve such
problems on a regular basis.

Getting Started with Scrum

At its core, Scrum is extremely simple; some might even say that it is just plain common sense.
However, if you have never managed a project with Scrum, I recommend that you start small. As
with most process change initiatives, success depends on people truly embracing the new
paradigm. The ScrumMaster coaching role during the initial stages is crucial for teams who want
to adopt Scrum and succeed with it. See the Scrum Resources sidebar for some good resources.

Scrum works very well with collocated teams of 5 to 10 members including the Product Owner,
developers, quality assurance, analysts, and the ScrumMaster. You can scale it up to work with
larger and distributed teams but I suggest that you start with a small collocated team.

Likewise, if you are using six-month iterations in your current development process, perhaps the
concept of two-week Sprints would be too much of a shock for your organization. In that case,
you might start with 30-day Sprints, see how those work for your team for a while, and then
decide whether you need to do shorter iterations.

Scrum provides a framework for cross-functional self-organized teams to work together towards
a common goal. The principles of visible progress and constant inspection provide transparency
to teams and allow them to quickly adapt to changes in the environment. In today's fast-paced
world of new technologies, changing requirements, and increased pressure to get to market,
Scrum's practices can help you deliver working software, with the right features, more often to
your customers.