/'

,~

//

/ /

_/

November 2009
Scrum: Developed ond susroined by Ken Schwaber and Jef! Sutherland

Q Scrum.org

ACKNOWLEDGEM

ENTS

GENERAL
Scrum is based on industry-accepted for decades. It is then Coplien once remarked best practices, used and proven As Jim it is what we set in an empirical to Jeff, "Everyone process theory.

will like Scrum;

already do when our back is against the walI."

PEOPLE
Of the thousands of people that have contributed working with Jeff Mckenna, During the to Scrum, we should and Ken Schwaber presented years, Mike And then five

single out those that were instrumental were Jeff Sutherland, and published everyone

in its first ten years. First there

with Mike Smith and Chris Martin. Scrum was first formally at OOPSLA 1995. next Beadle and Martine into what it is today. Devos made significant contributions.

else, without

whose help Scrum wouldn't

have been refined

HISTORY
The history of Scrum can already be considered long in the world of and IDX (now

software development. GE Medicai).

To honor the first places where it was tried and Inc., Fidelity Investments,

refined, we honor Individual,

2008-2009 Ken Schwaber and Jeff Sutherland,

All Rights Reserved

Page 12

PURPOSE
Scrum has been used to develop complex products since the early 1990s. This paper describes how to use Scrum to build products. Scrum is not a process or a technique for building products; is a framework development developed. rather, it within which you can employ various processes and upon them while

techniques. The role of Scrum is to surface the relative efficacy of your practices so th at you can improve providing a framework within which complex products can be

SCRUM THEORY
Scrum, which is grounded in empirical process control theory, employs an iterative, control incremental approach to optimize predictability and risk. Three pillars uphold every implementation of empirical

process control.

THE FIRST LEG IS TRANSPARENCY

Transparency ensures th at aspects of the process that affect the Not only outcome must be visible to those ma naging the outcomes. must these aspects be transparent,

but also what is being seen must

be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.

THE SECOND LEG IS INSPECTION

The various aspects of the process must be inspected frequently th at all enough so that unacceptable variances in the process can be detected. The frequency of inspeetion has to take into consideration processes are changed by the act of inspection. A conundrum occurs when the required frequency software development. of inspection exceeds the toleranee to this doesn't seem to be true of inspection of the process. Fortunately, people inspecting the work results.

The other factor is the skill and diligence of the

2008-2009

Ken Schwaber and Jeff Sutherland,

A" Rights Reserved

Page

13

THE THIRD LEG IS ADAPTATION

If the inspeetor determines resulting from the inspection acceptable th at one or more limits, and th at the must be aspects of the process are outside process or the material

product wil! be unacceptable,

the inspector must adjust the

being processed. The adjustment

made as quickly as possible to minimize further deviation. There are three points for inspection Daily Scrum meeting work dav. In addition, used to inspeet adaptations goal, and to make adaptations progress and adaptation in Scrum. The

is used to inspect progress toward the Sprint that optimize the value of the next the Release Goal and to make the Sprint Review and Planning meetings are toward Finally, the fulfilling,

that optimize the value of the next Sprint.

Sprint Retrospective and enjoyable.

is used to review the past Sprint and determine

what adaptations will make the next Sprint more productive,

SCRUM CONTENT
The Scrum framework consists of a set of Scrum Teams and their associated roles; Time-Boxes, Artifacts, and Rules. Scrum Teams are designed to optimize flexibility this end, they are self-organizing, work in iterations. who Each Scrum is ScrumMaster, Team for and productivity; roles: the 1) to the is

they are cross-functional, has three ensuring

and they process

responsible

understood and followed:

2) the Product Owner, who is responsible

for maximizing the value of the work th at the Scrum Team does; and 3) the Team, which does the work. The Team consists of developers with all the skilIs to turn the Product Owner's requirements into a potentially releasable piece of the product by the end of the Sprint. Scrum employs time boxes to create regularity. that are time-boxed include the Release Elements of Scrum Meeting, the

Planning

Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent
2008-2009
Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page 14

length throughout Scrum framework, after the other.

a development

effort.

All Sprints

use the same of the final

and all Sprints deliver an increment

product that is potentially

releasable. One Sprint starts immediately

Scrum employs four principal artifacts. prioritized

The Product Backlog is a

list of everything that might be needed in the product. The

Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product. A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint. Rules bind together roles, Scrum's
TIP When rules are not stated, the users of Scrum are expected to figure out what to do. Don 't try to figure out a perfect solution, because the problem usually changes quickly. Instead, try something and see how it works. The inspectand-adapt mechanisms of Scrum's empirical nature will guide you.

time-boxes, the

and artifacts. document. For

lts rules are described throughout body of this example, committed it is a Scrum rule that to turning the Product - can

only Team members - the people Backlog into an increment implementing

talk during a Daily Scrum. Ways of Scrum that are not are suggestions rules but rather

are described in "Tips" boxes.

SCRUM ROLES
The Scrum Team consists of the ScrumMaster, the Product Owner, and the Team. Scrum Team members are called "pigs." Everyone else is a "chicken. " Chickens cannot teil "pigs" how to do their work. Chickens and pigs come from the story, nA chicken and a pig are together when the chicken says, "Let's start a restaurant!"

2008-2009

Ken Schwaber and Jeff Sutherland,

All Rights Reserved

0. Page 15

The pig thinks it over and says, "What would we call this restaurant?" The chicken sevs, "Ham n' Eggs!" The pig says, "No thanks, I'd be committed, involved!" but you'd only be

THE SCRUMMASTR
The ScrumMaster ensuring that is responsible for the Scrum Team helps the The Scrum
TIP Ttie ScrumMaster works with ttie customers and management to identify and instantiate a Product Owner. The ScrumMaster tesebes ttie Product Owner how to do bis or her job. Product Owners are expected to know how to manage to optimize value using Scrum. If they don 't, we hold the ScrumMaster accountable.

adheres to Scrum va lues, practices, and rules. The ScrumMaster the Scrum Team adopt teaches and Scrum. the organization ScrumMaster

Team by coaching and by leading it to be more productive higher quality and and and produce The seltcrossproducts. use

ScrumMaster helps the Scrum Team understand management functionelitv.

The ScrumMaster also environment be optimized that for

TIP The ScrumMaster may be a member of the Team; for exempte, a developer performing Sprint tasks. riowever. this often leads to conflicts when the ScrumMaster has to choose between removing impediments and performing tesks. The Scrum Master should never be the Product Owner.

..

helps the Scrum Team do its best in an organizational may not vet complex these product changes,

development. helps make is called However, this

When the ScrumMaster "removing irnpedlments."

the ScrumMaster is self-organizing.

does not manage

the Scrum Team; the Scrum Team

2008-2009 Ken Schwaber and Jeff Sutherland,

All Rights Reserved

Page

16

THE PRODUCT OWNER

The Product managing work person Backlog vtslble knows highest the Owner is the one and only person responsible the Team Product the value the and ensuring

tor

TIP For commercial deveiopment, the Product Owner may be tbe product manager. For in-house development efforts, the Product Owner could be tlie manager of tne business tunetion that is being automated.

Backlog of the This it is the Product

performs. that have

maintains to

and ensures everyone. items

50

Everyone everyone

what

priority,

!_._- ------_.:.

knows what will be worked on. The Product not Owner a may is one that

person, Committees

committee. exist this person, have to

TIP The Product Owner can be a Team metnber, elso doing development work. This edditionel responsibilitv may cut into tbe Product Owner's ability to work with stskeholders. However, the Product Owner een never be the ScrumMaster.

advise or influence an item's the that it priority

I I

I
I

but people who want to change convince Companies may find methods Product adopt influences Owner. Scrum their

I!
I
I

tor

setting priorities and over time.

.... --'- _ _ ..J

requirements

For the Product Owner to succeed, evervene in the organization has to respect his or her decisions. No one is allowed to teil the Team to work trom a different set of priorities, and Teams aren't allowed to listen to anyone who says otherwise. The Product Owner's deerslons are visible of the Product Backlog. This visibility one. in the content and prioritization

requires the Product Owner to do his or her best, and it makes the role of Product Owner both a demanding and arewarding

o
2008-2009
Ken Schwabcr and Jeff Sutherland, All Rlghts Reserved

n. Page 17

THE TEAM
Teams of developers turn Product Backlog into increments of potentially functional; ski lis, shippable functionality every Sprint. Teams are also cross-

Team members must have all of the ski lis necessary to of work. Team members orten have specialized quality control, business analysis, a as prorarnmin.

create an increment such architecture, requirement important Everyone

user interface design, or data base design. However, the and turning it into a usa bie product - tend to be more

sktlls that Team member share - that is, the skill of addressing

than the ones that they do not. People who refuse to code chips in, even lf that requires learning new skills or

because they are architects or designers are not good fits for Teams. remembering old ones. There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either. Teams are also self-organizing. tells the Team how to turn shippable functionality. No one - not even the ScrumMaster -Product Backlog into increments of

The Team frgures this out on its own. Each

Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team's overall efficiency and effectiveness. The optimal size for a Team is seven people, plus or minus two. When there are fewer than frve Team members, there is less interaction and as aresuit less productivity gain. What's more, the Team may encounter skill constraints members, there is simply during parts of the Sprint and be unable to too much coordination required. Large

deliver a releasable piece of the product. If there are more than nine Teams generate too much complexity for an empirical process to

manage. However, we have encountered some successful Teams that have exceeded the upper and lower bounds of this size range. The Product Owner and ScrumMaster unless they are also pigs. roles are not included in this count

,~
2008-2009
Ken Schwaber and Jeff Sutherland, All Rights Reservcd

0. Page 18

Team composition Team membership composition.

may change at the end of a Sprint. is changed, the productivity gained

Every time from self-

organization is diminished. Care should be taken when changing Team

TIME-BOXES
The Time-Boxes Sprint, the in Scrum are the Release Planning Meeting, the Planning Meeting, the Sprint Review, the Sprint

Sprint Retrospective, and the Daily Scrum.

RELEASE PLANNING MEETING

The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations and communicate. can understand How Release planning answers the questions, "How can

we turn the vision into a winning product in best possible way? on Investment?" features nothing and

can we meet or exceed the desired customer satisfaction and Return The release plan establishes the goal of the release, Product Backlog, the major risks, and the overall that the release can then wil! contain. It also and should hold if progress basis. start work functionality the highest priority establishes

a pro babie deJivery date and cost that The organization inspect

changes.

make changes to this release plan on a Sprint-by-Sprint Release planning as an impediment is entirely that optional. If Scrum

teams

without the meeting, the absence of its artifacts wil! become apparent needs to be resolved. Work to resolve the impediment will become an item in the Product Backlog. Products are built iteratively an increment riskiest. product. using Scrum, wherein each Sprint creates starting with the most valuable and increments of the shippable slice of the entire

of the product,

More and more Sprints create additional Each increment is a potentially

product. When enough increments have been created for the Product to be of value, of use to its investors, the product is released.

2008-2009 Ken Schwaber and Jeff Suthcrland,

All Rights Reserved

Page

19

Most organizations

already
"

have a release .planninq

process, and in

most of these processes most of the planning is done at the beginning of the release and left unchanged as time passes. In Scrum release planning, an overall goal and probable outcomes consumed to build a traditional are defined. This release planning usually requires no more than 15-20% of the time an organization release plan. However, a planning at every Scrum release performs just-in-time planning every Sprint Review and

Sprint Planning meeting, as weil as daily just-in-time

Daily Scrum meeting. Overall, Scrum release efforts probably consurne slightly more effort than tradition release planning efforts. Release planning requires estimating and prioritizing the Product

Backlog for the Release. There are many techniques for doing so that lie outside the purview of Scrum but are nonetheless useful when used with it.

THE SPRINT
A Sprint is an iteration. are time-boxed. Sprint, the ScrumMaster would Both quality affect Team goals the the Sprint Sprints the
TIP the Team senses that it has overcommitted, it meets with the Product Owner to remove or reduce the scope of Product Back/og setecte for the Sprint. Ir tbe Team senses that it may have extra time, it can work with tbe Product Owner to select additional Product Back/og.

During

ensures Goal. and Sprints the Sprint

Ir

that no changes are made that composition remain Sprint.

constant

_'

throughout Planning development

contam and consist of the Sprint meeting, work, the

Review, and the Sprint Retrospective. with no time in between Sprints.

Sprints occur one after another,

A project is used to accomplish something; in software development,

is used to build a product definition or system. Every project

it

consists of a

of what is to be built, a plan to build it, the work done product. Every project has a
Q

according to the plan, and the resultant

horizon, which is to say the time frame for which the plan is good. If
2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved o.Page

I 10

the many

horizon

is

too

long, may

the
TIP When a Team begins Scrum, two-week Sprints al/ow it to team without wal/owing in uncerteintv. Sprints of this length een be synchronized witb otber Teams by adding two increments together.

definition may have changed, too varia bles have entered in, the risk may be too great, etc. Scum is a framework for a project whose horizon is no more where complexity than one month is long, enough there

that a longer horizon of the project has to be controlled at

is too risky. The predictability

least each month, and the risk that the project may go out of control or become unpredictable is contained at least each month. Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority the ScrumMaster. Sprint to cancel the Sprint, although he or the Team, or might a Sprint if the company In she may do so under influence from the stakeholders, Under what kind of circumstances obsolete. This could occur

need to be cancelled? Management may need to cancel a Sprint if the Goal becomes changes direction the circumstances. or if market or technology conditions change.

general, a Sprint should be cancelled if it no longer makes sense given However, because of the short duration of Sprints, it rarely makes sense to do so. When a Sprint is cancelled, any completed and "done" Product Backlog items are reviewed. They are accepted if they represent a potentially shippable increment. All other Product Backlog items are put back on initial estimates. Any work done on consume resources, to the the Product Backlog with their

them is assumed to be lost. Sprint terminations start another Sprint. Sprint terminations Team, and they are very uncommon.

since everyone has to regroup in another Sprint planning meeting to , are often traumatic

SPRINT PLANNING MEETING

The Sprint Planning meeting is when the iteration is planned.
Q

It is

time-boxed to eight hours for a one month Sprint.

2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved

For shorter Sprints,

o.Page

I 11

allocate approximately

5% of the total Sprint leng th to this meeting is when

and consists of two parts. The first part, a four hour time-box, another four-hour Sprint.

what wil! be done in the Sprint is decided upon. The second part, time box, is when the Team figures out how it is into a product increment during the going to build this functionality

There are two parts to the Sprint Planning Meeting: the "What?" part and the "How?" part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of "What?" Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out wh at functionality during the next Sprint. is to be developed is the Product The input to this meeting

Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint. Having selected the Product Backlog, a Sprint Goal is crafted. The

Sprint Goal is an objective that will be met through the implementation of the Product Backlog. This is a statement th at provides guidance to the Team on why it is building the increment. subset of the release goal. The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. Sprint could also be: through functionality a secure, For example, the goal for the above the client account modification middleware recoverable transaction "Automate The Sprint Goal is a

capability." As the Team works, it keeps this goal. in mind. In order to satisfy the goal, it implements the functionality Team collaborates with the Product and technology. If the and only partially work turns out to be harder than the Team had expected, then the Owner implement the functionality.

cP

20082009

Ken Schwaber and Jeff Sutherland,

All Rights Reserved

)_page

112

In the second part of the Sprint Planning Meeting, the Team addresses the question of "How?" During the second four hours of the Sprint Planning Meeting, the Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) into a done increment. designing, The Team usually starts the Team identifies by designing the work. While tasks. These tasks are the detailed

pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed 50 they can be done in less than one dav. This task list is called the Sprint Backlog. The Team setforganizes to assign and undertake Sprint. The Product Owner is present during the second part of the Sprint Planning Product make or with Team people provide advice. Meeting to clarify Backlog trade-offs. little and If work, to the it the help Team may The other to domain in this meeting. The Team realizes that it
TIP Usually, only 60-70% of the total Sprint Back/og will be aevtse in the Sprint Planning meeting. The rest is stubbed out for later eteilin, or given large estimates that wil! be decomposed later in the Sprint.

the work in the Sprint Backlog, during the

either during the Sprint Planning meeting or just-in-time

determines that it has toa much too the to renegotiate the Product Backlog Product attend Owner. invite in order

mayalso technicalor

A new Team often first realizes that it will either sink or swim

as a Team, not individually,

must rely on itself. As it realizes this, it starts to self-organize to take on the characteristics and behavior of a real Team.

SPRINT REVIEW
At the end of the Sprint, a Sprint Review meeting is held. This is a four hour time-boxed duration, meeting for one month Sprints. For Sprints of lesser this meeting must not consume more than 5% of the total

Sprint. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was just done. Based on that and changes to

2008-2009 Ken Schwaber and Jeff Sutherland,

All Rights Reserved

b.Page

113

the Product Backlog d~ring the Sprint, the presentation of the functionality

they collaborate intended

about what are meeting, with collaboration

the next things that could be done. This is an informal to foster about what to do next. The meeting includes at least the following elernents.

The Product

Owner identifies ran into, and

what has been done and what hasn't been done. The how it solved that these problems. and answers The Team th en The

Team discusses what went weil during the Sprint and what problems it demonstrates she projects the work is done questions.

Product Owner then discusses the Product Backlog as it stands. He or likely completion dates with various velocity The Sprint assumptions. The entire group then collaborates this means regarding valuable input to subsequent about what it has seen and what Review provides

what to do next.

Sprint Planning meeting.

SPRINT

RETROSPECTIVE
Retrospective meeting. encourages At this three the Scrum for and practices,

After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team has a Sprint hour, ttrne-boxed meeting within Team to revise, their development the next Sprint. the ScrumMaster

the Scrum

process framework techniques

process to make it more effective and enjoyable Many books document

that are helpful to

use in Retrospectives. The purpose of the Retrospective in regards to people, should identify items include definition turning the Sprint that-if Scrum and prioritize Team is to inspect how the last Sprint went process and tools. The inspection make things meeting even better. These tools, for

relationships,

the major items that went weil and those arrangements, "done." should to

done differently-could composition, methods the

of "done,"

of communication, Scrum the Team

and processes have the

Product Backlog items into something Retrospective, improvement changes measures become that

By the end of identified next empirical in the

actionable Sprint. inspection.

2008-2009

it impJements adaptation

These

Ken Schwaber and Jeff Sutherland,

All Rights Reserved

lPage 114

DAILY SCRUM
Each Team meets dallv for alS-minute place throughout explains: 1. What he or she has accomplished since the last meeting; 2. What he or she is going to do before the next meeting; and 3. What obstacles are in his or her way. Daily Scrums identify promote and quick improve remove communications, impediments to and eliminate development, improve other meetings, and of level inspeet and adapt meeting called the Daily Scrum. The Daily Scrum is at the same time and same the Sprints. During the meeting, each Team member

highlight

decision-making,

everyone's

project knowiedge. The ScrumMaster ensures that the Team has the meeting. The Team is responsible for conducting the Daily Scrum. The ScrumMaster teaches the Team to keep the Daily Scrum short by enforcing the rules and making sure that people speak briefly. The ScrumMaster also enforces the rule that chickens are not allowed to talk or in anyway interfere with the Daily Scrum. The DaHy Scrum is not a status meeting. It is not for anyone but the people transforming Team). Product Backlog the Product Backlog items into an increment (the to a Sprint Goal, and to these of the Follow-on The Daily Scrum is an inspection The Team has committed items. that Sprint

progress toward

Goal (the three questions).

meetings usually occur to make adaptations to the upcoming work in the Sprint. The intent is to optimize the probability that the Team will meet its Goal. This is a key inspeet and adapt meeting in the Scrum empirical process.

SCRUM ARTIFACTS
Scrum Artifacts include the Product Backlog, the Release Burndown, the Sprint Backlog, and the Sprint Burndown.

2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved

b_page 115

PRODUCT

BACKLOG AND RELEASE BURNDOWN

for the product that the Team(s) is developing are lts availability, and its prioritization. requirements. The

The requirements

listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, lays out the initially Product Backlog is never complete. The initial cut at developing it only known and best-understood Product Backlog evolves as the product and the environment changes to identify what the product needs to in which

it will be used evolves. The Backlog is dynamic in that it constantly be appropriate, competitive, also exists. The Product Backlog represents everything launch a successful product. necessary to develop and functions, and useful. As long as. a product exists, Product Backlog

It is a list of all features,

technologies, enhancements, and bug fixes that constitute the changes that wil! be made to the product . ._. .__._ . .._ for of future releases. Product and by Backlog items have the attributes a description, Priority priority, is driven estimate. are
TIP Product Back/og items are usueltv stete as User Stories. Use Cases af e appropriate as weil, but tnev are better for use in developing lire- or mission-

risk, value, and necessity. There many techniques for assessing these attributes.

i
,

L.=r:'... .. ___._ ___ ..

Top priority Product theactivities. its value. The higher Higher than priority lower information

Product Backlog is sorted in order of priority. Backlog drives the more immediate development is regarding

priority, the more urgent it is, the more it has been thought about, and consensus there Better backlog is clearer priority backlog. and has more detailed estimates

are made based on the greater

clarity and increased detail. The lower the priority, the less the detail, until you can barely make out the item. As a product is used, as its value increases, and as the marketplace provides feedback, the product's more exhaustive
(.) 2008-2009

backlog emerges into a larger and never stop changing.

.,",

list.

Requirements

Product
QPage 116

Ken Schwabcr

and Jeff Sutherland,

All Rights Reserved

Backlog Changes

is

a living in and

document. business
TIP Scrum Teams aften spetui 10% of each Sprint grooming the product back log to meet the ebove definition of the Product Back/ag. When qroometi to this level of granularity, the Product Back/ag items at the top of tne Product Backlog (hiqhest priority, greatest vetue) are decomposed so they fit within one Sprint. They have been anafyzed and tbouht through during the groaming process. When the Sprint Planning meeting occurs, these top priority Product Back/og items are welf understoad and easi/y setected.

requirements, technology, To minimize highest priority

market conditions, staffing cause the

changes in the Product Backlog. rework, only items need to be

detailed out. The Product Backlog items that wil! occupy the Teams for the upcoming several Sprints are item fine-grained, so can be having that any within been one the decomposed

done

duration of the Sprint. Multiple Scrum Teams often work together on the same product. work on items is can One Product Backlog ts used to describe the upcoming the Product. attribute then that groups

TIP Acceptance tests are often used as enother Product Back/ag item attribute. They can often supp/ant more detailed text descriptians with a testsbie description of what tne Product Backlog item must do when completed.

A Product Backlog Grouping

employed.

occur by feature set, technology, or architecture, by Scrum Team. and it is often used as a way to organize work

The Release Burndown graph records the sum of rerriaining Product Backlog estimated effort across time. The estimated effort is in whatever unit of work the Scrum Team and organization upon. The units of time are usually Sprints. Product Backlog item estimates are calculated initially Planning, and thereafter grooming they are reviewed and revised. However, during Release they can be The have decided

as they are created. During Product Backlog

updated at any time. The Team is responsible for all estimates.

20082009
Ken Schwaber and Jeff Sutherland, All Rghts Reserved

lPage 117

Product Owner may influence the Team by helping understand and select The trade-offs, Product but the keeps final an list estimate updated Release can be is made by the Team. Owner Product Backlog drawn Backlog TIP
In some orqenizetions, mare work is added to tne beckloq than is campleted. This may creete a trend fine thet is flat ar even slopes upwerds. Ta campensate tor this and reisin trensperencv, a new oor may be created when work is added ar subtreetea. The oor should add or remave anly significant changes and stioutd oe weil documented.

Burndown on the

posted at all times. A trend line based change in remaining work.

SPRINT BACKLOG AND SPRINT BURNDOWN

The Sprint Backlog conslsts of TIP
The trend fine may be unreliable for tbe first twa to three Sprints of a release unless tbe Teams have worked toaether betere, know the product weil, and understand the underfying technolagy.

the tasks the Team performs to turn Product Backlog items into a "done" increment. during Many the are developed Sprint

Planning Meeting. It is all of the work th at the Team identifies as necessary goal. to meet the Sprint Sprint Backlog items must

be decomposed. The decomposition

is enough 50 changes in progress

can be understood in the Daily Scrum. The Team modifies Sprint Backlog throughout the Sprint, as weil as

Sprint Backlog emerging during the Sprint. As it gets into individual tasks, it may find out that more or fewer tasks are needed, or that a given task wil! take more or less time than had been expected. As new work is required, the Team adds it to the Sprint Backlog. As tasks are worked on or completed, the hours of estimated removed. Only the Team can change its Sprint remaining work Backlog during

tor
a

each task is updated. When tasks are deemed unnecessary, they are Sprint. Only the Team can change the contents or the estimates. The Sprint Backlog is a highly visible, real time picture of the work that the
(0 20082009 Ken Schwaber and Jeff Sutherland. All Rights Reserved

lPage 118

Team plans to accomplish during the Sprint, and it belongs solely to the Team. Sprint Backlog Burndown is a graph of the amount of Sprint Backlog work remaining graph, determine in a Sprint across time in the Sprint. To create this how much work remains by summing the backlog

estimates every dav of the Sprint. The amount of work remaining tor a Sprint is the sum of the work remaining for all of Sprint Backlog. Keep track of these sums by dav and use them to create a graph th at shows the work remaining over time. By drawing a line through the points on the graph, the Team can manage its progress in completing a Sprint's work. Duration is not considered in Scrum. date interest. One of Scrum's rules pertains to the purpose of each Sprint, which is that to dever adheres increments to a of potentially shippable functionality working definition of "done." Work remaining variables and of
TIP Whenever possibie, hand draw ttie bumdown chart on a big sheet of paper displayed in ttie Team's work area. Teams are more likeiv to see a big, visible cbert trien thev are to look at Sprint burndown chart In Excel or a tooI.

are the

only

I
I
:

: 1

._ ..

f :

'

DONE
Scrum requires an increment every must for the to be functionality increment shippable, may implement Teams to build of product This potentially Owner To It immediately must be a Sprint.

.. --- ..... "'_-" ....-

,_,--'"" ..

"'

...

'.'

'--' .'.

-',

,,-~

TIP "Undone" werk IS of ten accumulated in a Product Back/ag item called "Undone Work" or "Implementation Work. " A5 ttiis work eccumuletes, tbe Product Back/ag burndown remeins more eccurete than tt it weren 't

Product

choose

functionality.

do 50, the increment must be "done." should

complete slice of the product. be additive to

eccumutetea.

Each increment all prior

I_~ ,,__. "._.'

,,

".. ,__ ,,

2008-2009

Ken Schwaber

and Jeff Sutherland,

All Rights Reserved

hPage 119

increments and thoroughly together.

tested, ensuring th at all increments work

In product development, asserting that functionality

is done might lead

someone to assume that it is at least cleanly coded, refactored, unit tested, built, and acceptance tested. Someone else might assume only that the code has been built. If everyone doesn't know what the definition of "done" is, the other two legs of empirical process control don't work. When someone describes something as done, everyone must understand what done means. Done defines wh at the Team means when it commits to "doinq" Product Backlog item documentation, documentation.
50

in a Sprint. the definition "done"

Some products of "done" increment

do not contain not include

does

A completely

includes all of the and testing

analysis, design, refactoring, programming, documentation for the increment non-functional

and all Product Backlog items in the increment. such as performance, stability, security, and

Testing includes unit, system, user, and regression testing, as weil as tests integration. Done includes any internationalization. vet able to include everything definition remaining Some Teams aren't in their can be

required for implementation

of done. This must be clear to the Product Owner. This work will have to be done before the product

implemented and used.

FINAL THOUGHTS
Some organizations within one Sprint. to infrastructure "undone" are incapable of building a complete all of the testing. In increment testing They may not vet have the automated complete

th is case, two

categories are created for each increment: work. The "undone"

the "done" work and the

work is the portion of each increment

th at wil! have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of "done" and the Product Owner understands the definition. "Undone" work is added to a Product Backlog item named "undone work" 50 it accumulates and

..
(1:) 20082009

Ken Scbwaber and J('ff Sutberland,

All Rights Reserved

QPage

120

correctly

reflects

on the

Release Burndown

graph.

This technique

creates transparency

in progress toward

a release. The inspeet and

adapt in the Sprint Review is as accurate as this transparency. For instance, stability, item, the if a Team is not able to do performance, and integration of this testing work to the programming, work that regression,

security,

for each Product Backlog can be done unit and documentation,

proportion

(analysis, design, refactoring, "done"

user testing) is calculated. Let's say that this proportion is six pieces of and four pieces on "undone." If the Team finishes a Product based on work" Backlog item of six units of work (the Team is estimating what it knows how to "do"), Product Backlog item wh en they are finished. Sprint by Sprint, the "undone" work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization's characteristics. Release Sprints are added to the end of any release to complete this "undone" work. The number of Sprints is unpredictable to the degree that the accumulation of "undone" work is not linear.

four is added to the "undone

7008-2009

Ken Schwaber and Jeff Sutherland,

All Rights Rcscrved

QPage 121