/

///',~

/

_/

November 2009

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

Q Scrum.org·

ACKNOWLEDGEM ENTS

GENERALScrum is based on industry-accepted best practices, used and provenfor decades. It is then set in an empirical process theory. As JimCoplien once remarked to Jeff, "Everyone will like Scrum; it is what wealready do when our back is against the walI."

PEOPLE

Of the thousands of people that have contributed to Scrum, we shouldsingle out those that were instrumental in its first ten years. First therewere Jeff Sutherland, working with Jeff Mckenna, and Ken Schwaberwith Mike Smith and Chris Martin. Scrum was first formally presentedand published at OOPSLA 1995. During the next five years, MikeBeadle and Martine Devos made significant contributions. And theneveryone else, without whose help Scrum wouldn't have been refinedinto what it is today.

HISTORY

The history of Scrum can already be considered long in the world ofsoftware development. To honor the first places where it was tried andrefined, we honor Individual, Inc., Fidelity Investments, and IDX (nowGE Medicai).

© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved n Page 12

PURPOSE

Scrum has been used to develop complex products since the early1990s. This paper describes how to use Scrum to build products.Scrum is not a process or a technique for building products; rather, itis a framework within which you can employ various processes andtechniques. The role of Scrum is to surface the relative efficacy of yourdevelopment practices so that you can improve upon them whileproviding a framework within which complex products can bedeveloped.

SCRUM THEORYScrum, which is grounded in empirical process control theory, employsan iterative, incremental approach to optimize predictability andcontrol risk. Three pillars uphold every implementation of empiricalprocess control.

THE FIRST LEG IS TRANSPARENCYTransparency ensures th at aspects of the process that affect theoutcome must be visible to those managing the outcomes. Not onlymust these aspects be transparent, but also what is being seen mustbe known. That is, when someone inspecting a process believes thatsomething is done; it must be equivalent to their definition of done.

THE SECOND LEG IS INSPECTIONThe various aspects of the process must be inspected frequentlyenough so that unacceptable variances in the process can be detected.The frequency of inspeetion has to take into consideration that allprocesses are changed by the act of inspection. A conundrum occurswhen the required frequency of inspection exceeds the toleranee toinspection of the process. Fortunately, this doesn't seem to be true ofsoftware development. The other factor is the skill and diligence of thepeople inspecting the work results.

© 2008-2009 Ken Schwaber and Jeff Sutherland, A" Rights Reserved n Page 13

THE THIRD LEG IS ADAPTATIONIf the inspeetor determines from the inspection th at one or moreaspects of the process are outside acceptable limits, and th at theresulting product wil! be unacceptable, the inspector must adjust theprocess or the material being processed. The adjustment must bemade as quickly as possible to minimize further deviation.

There are three points for inspection and adaptation in Scrum. TheDaily Scrum meeting is used to inspect progress toward the Sprintgoal, and to make adaptations that optimize the value of the nextwork dav. In addition, the Sprint Review and Planning meetings areused to inspeet progress toward the Release Goal and to makeadaptations that optimize the value of the next Sprint. Finally, theSprint Retrospective is used to review the past Sprint and determinewhat adaptations will make the next Sprint more productive, fulfilling,and enjoyable.

SCRUM CONTENTThe Scrum framework consists of a set of Scrum Teams and theirassociated roles; Time-Boxes, Artifacts, and Rules.

Scrum Teams are designed to optimize flexibility and productivity; tothis end, they are self-organizing, they are cross-functional, and theywork in iterations. Each Scrum Team has three roles: 1) theScrumMaster, who is responsible for ensuring the process isunderstood and followed: 2) the Product Owner, who is responsiblefor maximizing the value of the work th at the Scrum Team does; and3) the Team, which does the work. The Team consists of developerswith all the skilIs to turn the Product Owner's requirements into apotentially releasable piece of the product by the end of the Sprint.

Scrum employs time boxes to create regularity. Elements of Scrumthat are time-boxed include the Release Planning Meeting, theSprint Planning Meeting, the Sprint, the Daily Scrum, the SprintReview, and the Sprint Retrospective. The heart of Scrum is aSprint, which is an iteration of one month or less that is of consistent

© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved Q Page 14

length throughout a development effort. All Sprints use the sameScrum framework, and all Sprints deliver an increment of the finalproduct that is potentially releasable. One Sprint starts immediatelyafter the other.

Scrum employs four principal artifacts. The Product Backlog is aprioritized list of everything that might be needed in the product. TheSprint Backlog is a list of tasks to turn the Product Backlog for oneSprint into an increment of potentially shippable product. A burndownis a measure of remaining backlog over time. A Release Burndownmeasures remaining Product Backlog across the time of a release plan.A Sprint Burndown measures remaining Sprint Backlog itemsacross the time of a Sprint.

Rules bind together Scrum'stime-boxes, roles, and artifacts.lts rules are described throughoutthe body of this document. Forexample, it is a Scrum rule thatonly Team members - the peoplecommitted to turning the ProductBacklog into an increment - cantalk during a Daily Scrum. Ways ofimplementing Scrum that are notrules but rather are suggestionsare described in "Tips" boxes.

SCRUM ROLES

TIP

When rules are not stated, theusers of Scrum are expectedto figure out what to do. Don 'ttry to figure out a perfectsolution, because the problemusually changes quickly.Instead, try something andsee how it works. The inspect-and-adapt mechanisms ofScrum's empirical nature willguide you.

The Scrum Team consists of the ScrumMaster, the Product Owner, andthe Team. Scrum Team members are called "pigs." Everyone else is a"chicken. " Chickens cannot teil "pigs" how to do their work. Chickensand pigs come from the story,

nA chicken and a pig are together when the chicken says, "Let'sstart 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 thisrestaurant?"

The chicken sevs, "Ham n' Eggs!"

The pig says, "No thanks, I'd be committed, but you'd only beinvolved!"

THE SCRUMMASTÈR

..

The ScrumMaster is responsible forensuring that the Scrum Teamadheres to Scrum va lues, practices,and rules. The ScrumMaster helpsthe Scrum Team and theorganization adopt Scrum. TheScrumMaster teaches the ScrumTeam by coaching and by leading itto be more productive and producehigher quality products. TheScrumMaster helps the Scrum Teamunderstand and use selt-management and cross-functionelitv. The ScrumMaster alsohelps the Scrum Team do its best inan organizational environment thatmay not vet be optimized forcomplex product development.When the ScrumMaster helps makethese changes, this is called"removing irnpedlments." However,the ScrumMaster does not managethe Scrum Team; the Scrum Teamis self-organizing.

TIP

Ttie ScrumMaster works withttie customers andmanagement to identify andinstantiate a Product Owner.The ScrumMaster tesebesttie Product Owner how to dobis or her job. ProductOwners are expected toknow how to manage tooptimize value using Scrum.If they don 't, we hold theScrumMaster accountable.

TIPThe ScrumMaster may be amember of the Team; forexempte, a developerperforming Sprint tasks.riowever. this often leads toconflicts when theScrumMaster has to choosebetween removingimpediments and performingtesks. The Scrum Mastershould never be the ProductOwner.

© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved h Page 16

1

THE PRODUCT OWNERThe Product Owner is the oneand only person responsible tormanaging the Product Backlogand ensuring the value of thework the Team performs. Thisperson maintains the ProductBacklog and ensures that it isvtslble to everyone. Everyoneknows what items have thehighest priority, 50 everyoneknows what will be worked on.

The Product Owner is oneperson, not aCommittees may

committee.exist that

advise or influence this person,but people who want to changean item's priority have toconvince the Product Owner.Companies that adopt Scrummay find it influences theirmethods tor setting priorities andrequirements over time.

TIP

For commercial deveiopment,the Product Owner may be tbeproduct manager. For in-housedevelopment efforts, theProduct Owner could be tliemanager of tne businesstunetion that is beingautomated.

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

For the Product Owner to succeed, evervene in the organization has torespect his or her decisions. No one is allowed to teil the Team to worktrom a different set of priorities, and Teams aren't allowed to listen toanyone who says otherwise. The Product Owner's deerslons are visiblein the content and prioritization of the Product Backlog. This visibilityrequires the Product Owner to do his or her best, and it makes the roleof Product Owner both a demanding and arewarding one.

TIP

The Product Owner can be aTeam metnber, elso doingdevelopment work. Thisedditionel responsibilitv maycut into tbe Product Owner'sability to work withstskeholders. However, theProduct Owner een never bethe ScrumMaster.

iII

II

I!II.... --'-__..J

© 2008-2009 Ken Schwabcr and Jeff Sutherland, All Rlghts Reservedon. Page 17

THE TEAMTeams of developers turn Product Backlog into increments ofpotentially shippable functionality every Sprint. Teams are also cross-functional; Team members must have all of the ski lis necessary tocreate an increment of work. Team members orten have specializedski lis, such as proçrarnminç. quality control, business analysis,architecture, user interface design, or data base design. However, thesktlls that Team member share - that is, the skill of addressing arequirement and turning it into a usabie product - tend to be moreimportant than the ones that they do not. People who refuse to codebecause they are architects or designers are not good fits for Teams.Everyone chips in, even lf that requires learning new skills orremembering old ones. There are no titles on Teams, and there are noexceptions to this rule. Teams do not contain sub-Teams dedicated toparticular domains like testing or business analysis, either.

Teams are also self-organizing. No one - not even the ScrumMaster --tells the Team how to turn Product Backlog into increments ofshippable functionality. The Team frgures this out on its own. EachTeam member applies his or her expertise to all of the problems. Thesynergy that results improves the entire Team's overall efficiency andeffectiveness.

The optimal size for a Team is seven people, plus or minus two. Whenthere are fewer than frve Team members, there is less interaction andas aresuit less productivity gain. What's more, the Team mayencounter skill constraints during parts of the Sprint and be unable todeliver a releasable piece of the product. If there are more than ninemembers, there is simply too much coordination required. LargeTeams generate too much complexity for an empirical process tomanage. However, we have encountered some successful Teams thathave exceeded the upper and lower bounds of this size range. TheProduct Owner and ScrumMaster roles are not included in this countunless they are also pigs.

© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reservcd,~0. Page 18

Team composition may change at the end of a Sprint. Every timeTeam membership is changed, the productivity gained from self-organization is diminished. Care should be taken when changing Teamcomposition.

TIME-BOXESThe Time-Boxes in Scrum are the Release Planning Meeting, theSprint, the Sprint Planning Meeting, the Sprint Review, theSprint Retrospective, and the Daily Scrum.

RELEASE PLANNING MEETINGThe purpose of release planning is to establish a plan and goals thatthe Scrum Teams and the rest of the organizations can understandand communicate. Release planning answers the questions, "How canwe turn the vision into a winning product in best possible way? Howcan we meet or exceed the desired customer satisfaction and Returnon Investment?" The release plan establishes the goal of the release,the highest priority Product Backlog, the major risks, and the overallfeatures and functionality that the release wil! contain. It alsoestablishes a pro babie deJivery date and cost that should hold ifnothing changes. The organization can then inspect progress andmake changes to this release plan on a Sprint-by-Sprint basis.

Release planning is entirely optional. If Scrum teams start workwithout the meeting, the absence of its artifacts wil! become apparentas an impediment that needs to be resolved. Work to resolve theimpediment will become an item in the Product Backlog.

Products are built iteratively using Scrum, wherein each Sprint createsan increment of the product, starting with the most valuable andriskiest. More and more Sprints create additional increments of theproduct. Each increment is a potentially shippable slice of the entireproduct. When enough increments have been created for the Productto be of value, of use to its investors, the product is released.

© 2008-2009 Ken Schwaber and Jeff Suthcrland, All Rights Reserved h Page 19

Most organizations already have a release .planninq process, and in"

most of these processes most of the planning is done at the beginningof the release and left unchanged as time passes. In Scrum releaseplanning, an overall goal and probable outcomes are defined. Thisrelease planning usually requires no more than 15-20% of the time anorganization consumed to build a traditional release plan. However, aScrum release performs just-in-time planning every Sprint Review andSprint Planning meeting, as weil as daily just-in-time planning at everyDaily Scrum meeting. Overall, Scrum release efforts probably consurneslightly more effort than tradition release planning efforts.

Release planning requires estimating and prioritizing the ProductBacklog for the Release. There are many techniques for doing so thatlie outside the purview of Scrum but are nonetheless useful when usedwith it.

THE SPRINTA Sprint is an iteration. Sprintsare time-boxed. During theSprint, the ScrumMaster ensuresthat no changes are made thatwould affect the Sprint Goal.Both Team composition andquality goals remain constantthroughout the Sprint. Sprintscontam and consist of the SprintPlanning meeting, thedevelopment work, the SprintReview, and the Sprint Retrospective. Sprints occur one after another,with no time in between Sprints.

TIP

Ir the Team senses that it hasovercommitted, it meets withthe Product Owner to removeor reduce the scope of ProductBack/og setecteä for the Sprint.Ir tbe Team senses that it mayhave extra time, it can workwith tbe Product Owner toselect additional ProductBack/og.

_'

A project is used to accomplish something; in software development, itis used to build a product or system. Every project consists of adefinition of what is to be built, a plan to build it, the work doneaccording to the plan, and the resultant product. Every project has ahorizon, which is to say the time frame for which the plan is good. If

Q© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved o.Page I 10

the horizon is too long, thedefinition may have changed, toomany varia bles may haveentered in, the risk may be toogreat, etc. Scum is a frameworkfor a project whose horizon is nomore than one month long,where there is enoughcomplexity that a longer horizonis too risky. The predictability of the

TIP

When a Team begins Scrum,two-week Sprints al/ow it toteam without wal/owing inuncerteintv. Sprints of thislength een be synchronized witbotber Teams by adding twoincrements together.

project has to be controlled atleast each month, and the risk that the project may go out of controlor become unpredictable is contained at least each month.

Sprints can be cancelled before the Sprint time box is over. Only theProduct Owner has the authority to cancel the Sprint, although he orshe may do so under influence from the stakeholders, the Team, orthe ScrumMaster. Under what kind of circumstances might a Sprintneed to be cancelled? Management may need to cancel a Sprint if theSprint Goal becomes obsolete. This could occur if the companychanges direction or if market or technology conditions change. Ingeneral, a Sprint should be cancelled if it no longer makes sense giventhe circumstances. 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 Backlogitems are reviewed. They are accepted if they represent a potentiallyshippable increment. All other Product Backlog items are put back onthe Product Backlog with their initial estimates. Any work done onthem is assumed to be lost. Sprint terminations consume resources,since everyone has to regroup in another Sprint planning meeting to,start another Sprint. Sprint terminations are often traumatic to theTeam, and they are very uncommon.

SPRINT PLANNING MEETINGThe Sprint Planning meeting is when the iteration is planned. It istime-boxed to eight hours for a one month Sprint. For shorter Sprints,

Q© 2008-2009KenSchwaberand Jeff Sutherland, All RightsReserved o.Page I 11

allocate approximately 5% of the total Sprint leng th to this meetingand consists of two parts. The first part, a four hour time-box, is whenwhat wil! be done in the Sprint is decided upon. The second part,another four-hour time box, is when the Team figures out how it isgoing to build this functionality into a product increment during theSprint.

There are two parts to the Sprint Planning Meeting: the "What?" partand the "How?" part. Some Scrum Teams combine the two. In the firstpart, the Scrum Team addresses the question of "What?" Here, theProduct Owner presents the top priority Product Backlog to the Team.They work together to figure out what functionality is to be developedduring the next Sprint. The input to this meeting is the ProductBacklog, the latest increment of product, the capacity of the Team,and past performance of the Team. The amount of backlog the Teamselects is solely up to the Team. Only the Team can assess what it canaccomplish over the upcoming Sprint.

Having selected the Product Backlog, a Sprint Goal is crafted. TheSprint Goal is an objective that will be met through the implementationof the Product Backlog. This is a statement th at provides guidance tothe Team on why it is building the increment. The Sprint Goal is asubset of the release goal.

The reason for having a Sprint Goal is to give the Team some wiggleroom regarding the functionality. For example, the goal for the aboveSprint could also be: "Automate the client account modificationfunctionality through a secure, recoverable transaction middlewarecapability." As the Team works, it keeps this goal. in mind. In order tosatisfy the goal, it implements the functionality and technology. If thework turns out to be harder than the Team had expected, then theTeam collaborates with the Product Owner and only partiallyimplement the functionality.

cP 2008·2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved Î)_page 112

In the second part of the Sprint Planning Meeting, the Team addressesthe question of "How?" During the second four hours of the SprintPlanning Meeting, the Team figures out how it will turn the ProductBacklog selected during Sprint Planning Meeting (What) into a doneincrement. The Team usually starts by designing the work. Whiledesigning, the Team identifies tasks. These tasks are the detailedpieces of work needed to convert the Product Backlog into workingsoftware. Tasks should have decomposed 50 they can be done in lessthan one dav. This task list is called the Sprint Backlog. The Team setf-organizes to assign and undertake the work in the Sprint Backlog,either during the Sprint Planning meeting or just-in-time during theSprint.

The Product Owner is present duringPlanning Meeting to clarify theProduct Backlog and to helpmake trade-offs. If the Teamdetermines that it has toa muchor too little work, it mayrenegotiate the Product Backlogwith the Product Owner. TheTeam mayalso invite otherpeople to attend in order to

the second part of the Sprint

TIP

Usually, only 60-70% of thetotal Sprint Back/og will beaevtseä in the Sprint Planningmeeting. The rest is stubbedout for later äeteilinç, or givenlarge estimates that wil! bedecomposed later in the Sprint.

provide technicalor domainadvice. A new Team often first realizes that it will either sink or swimas a Team, not individually, in this meeting. The Team realizes that itmust rely on itself. As it realizes this, it starts to self-organize to takeon the characteristics and behavior of a real Team.

SPRINT REVIEWAt the end of the Sprint, a Sprint Review meeting is held. This is a fourhour time-boxed meeting for one month Sprints. For Sprints of lesserduration, this meeting must not consume more than 5% of the totalSprint. During the Sprint Review, the Scrum Team and stakeholderscollaborate 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, they collaborate about what arethe next things that could be done. This is an informal meeting, withthe presentation of the functionality intended to foster collaborationabout what to do next.

The meeting includes at least the following elernents. The ProductOwner identifies what has been done and what hasn't been done. TheTeam discusses what went weil during the Sprint and what problems itran into, and how it solved these problems. The Team th endemonstrates the work that is done and answers questions. TheProduct Owner then discusses the Product Backlog as it stands. He orshe projects likely completion dates with various velocity assumptions.The entire group then collaborates about what it has seen and whatthis means regarding what to do next. The Sprint Review providesvaluable input to subsequent Sprint Planning meeting.

SPRINT RETROSPECTIVEAfter the Sprint Review and prior to the next Sprint Planning meeting,the Scrum Team has a Sprint Retrospective meeting. At this threehour, ttrne-boxed meeting the ScrumMaster encourages the ScrumTeam to revise, within the Scrum process framework and practices,their development process to make it more effective and enjoyable forthe next Sprint. Many books document techniques that are helpful touse in Retrospectives.

The purpose of the Retrospective is to inspect how the last Sprint wentin regards to people, relationships, process and tools. The inspectionshould identify and prioritize the major items that went weil and thoseitems that-if done differently-could make things even better. Theseinclude Scrum Team composition, meeting arrangements, tools,definition of "done," methods of communication, and processes forturning Product Backlog items into something "done." By the end ofthe Sprint Retrospective, the Scrum Team should have identifiedactionable improvement measures that it impJements in the nextSprint. These changes become the adaptation to the empiricalinspection.

© 2008-2009 Ken Schwaber and Jeff Sutherland, All Rights Reserved ÏlPage 114

DAILY SCRUMEach Team meets dallv for alS-minute inspeet and adapt meetingcalled the Daily Scrum. The Daily Scrum is at the same time and sameplace throughout the Sprints. During the meeting, each Team memberexplains:

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 improve communications, eliminate other meetings,identify and remove impediments to development, highlight andpromote quick decision-making, and improve everyone's level ofproject knowiedge.

The ScrumMaster ensures that the Team has the meeting. The Team isresponsible for conducting the Daily Scrum. The ScrumMaster teachesthe Team to keep the Daily Scrum short by enforcing the rules andmaking sure that people speak briefly. The ScrumMaster also enforcesthe rule that chickens are not allowed to talk or in anyway interferewith the Daily Scrum.

The DaHy Scrum is not a status meeting. It is not for anyone but thepeople transforming the Product Backlog items into an increment (theTeam). The Team has committed to a Sprint Goal, and to theseProduct Backlog items. The Daily Scrum is an inspection of theprogress toward that Sprint Goal (the three questions). Follow-onmeetings usually occur to make adaptations to the upcoming work inthe Sprint. The intent is to optimize the probability that the Team willmeet its Goal. This is a key inspeet and adapt meeting in the Scrumempirical process.

SCRUM ARTIFACTSScrum 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 BURNDOWNThe requirements for the product that the Team(s) is developing arelisted in the Product Backlog. The Product Owner is responsible for theProduct Backlog, its contents, lts availability, and its prioritization.Product Backlog is never complete. The initial cut at developing it onlylays out the initially known and best-understood requirements. TheProduct Backlog evolves as the product and the environment in whichit will be used evolves. The Backlog is dynamic in that it constantlychanges to identify what the product needs to be appropriate,competitive, and useful. As long as. a product exists, Product Backlogalso exists.

The Product Backlog represents everything necessary to develop andlaunch a successful product. It is a list of all features, functions,technologies, enhancements, and bug fixes that constitute the changesthat wil! be made to the product . ._. .__._.._ .for future releases. ProductBacklog items have the attributesof a description, priority, andestimate. Priority is driven byrisk, value, and necessity. Thereare many techniques forassessing these attributes.

TIP

Product Back/og items areusueltv steteä as User Stories.Use Cases af e appropriate as

i weil, but tnev are better for use, in developing lire- or mission-

L.=r:'...___..__.._._Product Backlog is sorted in order of priority. Top priority ProductBacklog drives immediate development activities. The higher the-priority, the more urgent it is, the more it has been thought about, andthe more consensus there is regarding its value. Higher prioritybacklog is clearer and has more detailed information than lowerpriority backlog. Better estimates are made based on the greaterclarity 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 marketplaceprovides feedback, the product's backlog emerges into a larger andmore exhaustive list. Requirements never stop changing. Product

(.é) 2008-2009 Ken Schwabcr and Jeff Sutherland, All Rights Reserved.,",

QPage 116

Backlog is a living document.Changes in businessrequirements, market conditions,technology, and staffing causechanges in the Product Backlog.To minimize rework, only thehighest priority items need to bedetailed out. The Product Backlogitems that wil! occupy the Teamsfor the upcoming several Sprintsare fine-grained, having beendecomposed so that any oneitem can be done within theduration of the Sprint.

Multiple Scrum Teams often worktogether on the same product.One Product Backlog ts used todescribe the upcoming work onthe Product. A Product Backlogattribute that groups items isthen employed. Grouping canoccur by feature set, technology,or architecture, and it is oftenused as a way to organize workby Scrum Team.

TIP

Scrum Teams aften spetui 10%of each Sprint grooming theproduct backlog to meet theebove definition of the ProductBack/ag. When qroometi to thislevel of granularity, the ProductBack/ag items at the top of tneProduct Backlog (hiqhestpriority, greatest vetue) aredecomposed so they fit withinone Sprint. They have beenanafyzed and tbouçht throughduring the groaming process.When the Sprint Planningmeeting occurs, these toppriority Product Back/og itemsare welf understoad and easi/ysetected.

The Release Burndown graph records the sum of rerriaining ProductBacklog estimated effort across time. The estimated effort is inwhatever unit of work the Scrum Team and organization have decidedupon. The units of time are usually Sprints.

TIP

Acceptance tests are often usedas enother Product Back/agitem attribute. They can oftensupp/ant more detailed textdescriptians with a testsbiedescription of what tne ProductBacklog item must do whencompleted.

Product Backlog item estimates are calculated initially during ReleasePlanning, and thereafter as they are created. During Product Backloggrooming they are reviewed and revised. However, they can beupdated at any time. The Team is responsible for all estimates. The

© 2008·2009 Ken Schwaber and Jeff Sutherland, All Rîghts Reserved ÎlPage 117

Product Owner may influence theTeam by helping understand andselect trade-offs, but the finalestimate is made by the Team.The Product Owner keeps anupdated Product Backlog listRelease Backlog Burndownposted at all times. A trend linecan be drawn based on thechange in remaining work.

SPRINT BACKLOG ANDSPRINT BURNDOWN

TIP

In some orqenizetions, marework is added to tne beckloqthan is campleted. This maycreete a trend fine thet is flat areven slopes upwerds. Tacampensate tor this and reisintrensperencv, a new ûoor maybe created when work is addedar subtreetea. The üoor shouldadd or remave anly significantchanges and stioutd oe weildocumented.

The Sprint Backlog conslsts ofthe tasks the Team performs toturn Product Backlog items into a"done" increment. Many aredeveloped during the SprintPlanning Meeting. It is all of thework th at the Team identifies asnecessary to meet the Sprintgoal. Sprint Backlog items mustbe decomposed. The decomposition is enough 50 changes in progresscan be understood in the Daily Scrum.

TIP

The trend fine may beunreliable for tbe first twa tothree Sprints of a releaseunless tbe Teams have workedtoaether betere, know theproduct weil, and understandthe underfying technolagy.

The Team modifies Sprint Backlog throughout the Sprint, as weil asSprint Backlog emerging during the Sprint. As it gets into individualtasks, it may find out that more or fewer tasks are needed, or that agiven task wil! take more or less time than had been expected. As newwork is required, the Team adds it to the Sprint Backlog. As tasks areworked on or completed, the hours of estimated remaining work toreach task is updated. When tasks are deemed unnecessary, they areremoved. Only the Team can change its Sprint Backlog during aSprint. Only the Team can change the contents or the estimates. TheSprint Backlog is a highly visible, real time picture of the work that the

(0 2008·2009 Ken Schwaber and Jeff Sutherland. All Rights Reserved ÎlPage 118

Team plans to accomplish during the Sprint, and it belongs solely tothe Team.

Sprint Backlog Burndown is a graph of the amount of Sprint Backlogwork remaining in a Sprint across time in the Sprint. To create thisgraph, determine how much work remains by summing the backlogestimates every dav of the Sprint. The amount of work remaining tor aSprint is the sum of the work remaining for all of Sprint Backlog. Keeptrack of these sums by dav and use them to create a graph th at showsthe work remaining over time. By drawing a line through the points onthe graph, the Team can manage its progress in completing a Sprint'swork. Duration is not consideredin Scrum. Work remaining anddate are the only variables ofinterest.

One of Scrum's rules pertains tothe purpose of each Sprint, whichis to deüver increments ofpotentially shippable functionalitythat adheres to a workingdefinition of "done."

DONEScrum requires Teams to buildan increment of productfunctionality every Sprint. Thisincrement must be potentiallyshippable, for Product Ownermay choose to immediatelyimplement the functionality. Todo 50, the increment must be acomplete slice of the product. Itmust be "done." Each incrementshould be additive to all prior

TIP

Whenever possibie, hand drawttie bumdown chart on a bigsheet of paper displayed in ttieTeam's work area. Teams are

I more likeiv to see a big, visibleI cbert trien thev are to look at: Sprint burndown chart In Excel1 or a tooI. ': fL ._.. , :

..--- ..... "'_-" ....- ,_,--'"" .."' ... '.' '--' .'. -', ,,-~•·· TIP•

"Undone" werk IS of tenaccumulated in a ProductBack/ag item called "UndoneWork" or "ImplementationWork. " A5 ttiis workeccumuletes, tbe ProductBack/ag burndown remeinsmore eccurete than tt it weren 't

I eccumutetea.I_~ ,,__ . "._.' ,, ".. ,__ ,, ,

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

increments and thoroughly tested, ensuring that all increments worktogether.

In product development, asserting that functionality is done might leadsomeone to assume that it is at least cleanly coded, refactored, unittested, built, and acceptance tested. Someone else might assume onlythat the code has been built. If everyone doesn't know what thedefinition of "done" is, the other two legs of empirical process controldon't work. When someone describes something as done, everyonemust understand what done means.

Done defines what the Team means when it commits to "doinq" aProduct Backlog item in a Sprint. Some products do not containdocumentation, 50 the definition of "done" does not includedocumentation. A completely "done" increment includes all of theanalysis, design, refactoring, programming, documentation and testingfor the increment and all Product Backlog items in the increment.Testing includes unit, system, user, and regression testing, as weil asnon-functional tests such as performance, stability, security, andintegration. Done includes any internationalization. Some Teams aren'tvet able to include everything required for implementation in theirdefinition of done. This must be clear to the Product Owner. Thisremaining work will have to be done before the product can beimplemented and used.

FINAL THOUGHTSSome organizations are incapable of building a complete incrementwithin one Sprint. They may not vet have the automated testinginfrastructure to complete all of the testing. In th is case, twocategories are created for each increment: the "done" work and the"undone" work. The "undone" work is the portion of each incrementth at wil! have to be completed at a later time. The Product Ownerknows exactly what he or she is inspecting at the end of the Sprintbecause the increment meets the definition of "done" and the ProductOwner understands the definition. "Undone" work is added to aProduct Backlog item named "undone work" 50 it accumulates and

(1:) 2008·2009 Ken Scbwaber and J('ff Sutberland, All Rights Reserved..QPage 120

correctly reflects on the Release Burndown graph. This techniquecreates transparency in progress toward a release. The inspeet andadapt in the Sprint Review is as accurate as this transparency.

For instance, if a Team is not able to do performance, regression,stability, security, and integration testing for each Product Backlogitem, the proportion of this work to the work that can be done(analysis, design, refactoring, programming, documentation, unit anduser testing) is calculated. Let's say that this proportion is six pieces of"done" and four pieces on "undone." If the Team finishes a ProductBacklog item of six units of work (the Team is estimating based onwhat it knows how to "do"), four is added to the "undone work"Product Backlog item when they are finished.

Sprint by Sprint, the "undone" work of each increment is accumulatedand must be addressed prior to releasing the product. This work isaccumulated linearly although it actually has some sort of exponentialaccumulation 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 degreethat the accumulation of "undone" work is not linear.

© 7008-2009 Ken Schwaber and Jeff Sutherland, All Rights Rcscrved QPage 121