2016 scrum-guide-us

The Scrum GuideTM
The Definitive Guide to Scrum:
The Rules of the Game
July 2016
Developed and sustained by Ken Schwaber and Jeff Sutherland

©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you
have read and agree to be bound by the terms of theAttribution Share-Alike license of Creative Commons.
Page | 2
Table of Contents
Purpose of the Scrum Guide....................................................................................................3
Definition of Scrum.................................................................................................................3
Scrum Theory.........................................................................................................................3
Scrum Values..........................................................................................................................4
The Scrum Team.....................................................................................................................5
The Product Owner.............................................................................................................5
The Development Team......................................................................................................6
The Scrum Master...............................................................................................................6
Scrum Events..........................................................................................................................7
The Sprint...........................................................................................................................8
SprintPlanning...................................................................................................................9
Daily Scrum......................................................................................................................11
Sprint Review ...................................................................................................................11
Sprint Retrospective..........................................................................................................12
Scrum Artifacts.....................................................................................................................13
Product Backlog................................................................................................................13
Sprint Backlog...................................................................................................................14
Increment........................................................................................................................15
Artifact Transparency............................................................................................................15
Definition of “Done”.........................................................................................................16
End Note..............................................................................................................................16
Acknowledgements ..............................................................................................................17
People..............................................................................................................................17
History.............................................................................................................................17

Page | 3
Purpose of the Scrum Guide
Scrum isa frameworkfordevelopingandsustainingcomplexproducts.ThisGuide containsthe
definitionof Scrum. Thisdefinitionconsistsof Scrum’sroles, events, artifacts,andthe rulesthat
bindthemtogether.KenSchwaberandJeff SutherlanddevelopedScrum;the ScrumGuide is
writtenandprovidedbythem. Together,they standbehindthe ScrumGuide.
Definition of Scrum
Scrum (n):A frameworkwithinwhichpeople canaddresscomplexadaptiveproblems,while
productivelyandcreativelydeliveringproductsof the highestpossible value.
Scrum is:
 Lightweight
 Simple tounderstand
 Difficulttomaster
Scrum isa processframeworkthathasbeenusedtomanage complex productdevelopment
since the early1990s. Scrum isnot a processor a technique forbuildingproducts;rather,itisa
frameworkwithinwhichyoucanemployvariousprocessesandtechniques.Scrummakesclear
the relative efficacyof yourproductmanagementanddevelopmentpracticessothatyoucan
improve.
The Scrum frameworkconsistsof ScrumTeamsand theirassociated roles, events, artifacts,and
rules.Each componentwithinthe frameworkservesaspecificpurpose andisessentialto
Scrum’ssuccessand usage.
The rulesof Scrumbindtogetherthe events,roles,andartifacts,governingthe relationshipsand
interactionbetweenthem.The rulesof Scrumare describedthroughoutthe bodyof this
document.
Specifictacticsforusingthe Scrum frameworkvaryandare describedelsewhere.
Scrum Theory
Scrum isfounded onempirical processcontrol theory,orempiricism. Empiricismassertsthat
knowledge comesfromexperience and makingdecisionsbased onwhatis known. Scrum
employsaniterative, incremental approachtooptimizepredictabilityandcontrol risk.
Three pillarsupholdeveryimplementationof empirical processcontrol:transparency,
inspection,andadaptation.

Page | 4
Transparency
Significantaspectsof the processmustbe visibletothose responsible forthe outcome.
Transparencyrequires those aspectsbe definedby acommon standardso observersshare a
commonunderstandingof whatisbeing seen.
For example:
 A commonlanguage referringtothe process mustbe sharedbyall participants;and,
 Those performingthe workandthose acceptingthe workproductmust share a common
definitionof “Done”.
Inspection
Scrum usersmustfrequentlyinspectScrumartifactsandprogresstowarda SprintGoal to detect
undesirablevariances.Theirinspectionshouldnotbe sofrequentthat inspection getsinthe way
of the work.Inspectionsare mostbeneficialwhendiligentlyperformedbyskilledinspectorsat
the pointof work.
Adaptation
If an inspectordeterminesthatone ormore aspectsof a process deviate outside acceptable
limits,andthatthe resultingproductwill be unacceptable,the processorthe material being
processed mustbe adjusted.Anadjustmentmustbe made as soonas possible tominimize
furtherdeviation.
Scrum prescribesfourformal eventsforinspectionandadaptation,asdescribedinthe Scrum
Eventssection of thisdocument:
 SprintPlanning
 DailyScrum
 SprintReview
 SprintRetrospective
Scrum Values
Whenthe valuesof commitment,courage,focus,opennessandrespect are embodiedandlived
by the Scrum Team,the Scrum pillarsof transparency,inspection,andadaptationcome tolife
and build trustforeveryone.The ScrumTeammembers learnandexplore thosevaluesasthey
workwiththe Scrum events,rolesandartifacts.
Successful use of Scrum dependsonpeople becomingmore proficientinlivingthesefivevalues.
People personallycommittoachievingthe goalsof the ScrumTeam.The Scrum Team members
have courage to do the right thingandwork ontough problems.Everyone focusesonthe work
of the Sprintandthe goalsof the ScrumTeam. The Scrum Teamand itsstakeholdersagree tobe
openaboutall the workand the challengeswith performingthe work. ScrumTeammembers
respecteachotherto be capable,independent people.

Page | 5
The Scrum Team
The Scrum Team consistsof a ProductOwner,the DevelopmentTeam,andaScrum Master.
Scrum Teams are self-organizingand cross-functional.Self-organizingteamschoose how bestto
accomplishtheirwork,ratherthan beingdirectedby others outside the team.Cross-functional
teamshave all competenciesneeded toaccomplishthe workwithoutdependingonothersnot
part of the team.The team model inScrumisdesignedtooptimize flexibility,creativity,and
productivity.
Scrum Teams deliverproducts iterativelyandincrementally,maximizingopportunitiesfor
feedback.Incremental deliveries of “Done”productensure apotentially usefulversionof
workingproductisalwaysavailable.
The Product Owner
The Product Owneris responsible formaximizingthe value of the productandthe workof the
DevelopmentTeam.How thisisdone mayvary widelyacrossorganizations,ScrumTeams,and
individuals.
The Product Owneristhe sole personresponsibleformanagingthe ProductBacklog.Product
Backlogmanagementincludes:
 ClearlyexpressingProductBacklogitems;
 Orderingthe itemsinthe ProductBacklog to bestachieve goalsandmissions;
 Optimizingthe valueof the workthe DevelopmentTeam performs;
 Ensuringthat the ProductBacklogis visible,transparent, andcleartoall,andshowswhat
the Scrum Team will workonnext;and,
 Ensuringthe DevelopmentTeamunderstandsitemsinthe ProductBacklogtothe level
needed.
The Product Ownermaydo the above work,or have the DevelopmentTeamdoit.However,the
ProductOwnerremainsaccountable.
The Product Ownerisone person,nota committee. The ProductOwnermayrepresentthe
desiresof acommittee inthe ProductBacklog, butthose wantingto change a ProductBacklog
item’spriority mustaddress the ProductOwner.
For the ProductOwnerto succeed,the entire organization mustrespecthisorherdecisions. The
ProductOwner’sdecisionsare visible inthe contentand orderingof the ProductBacklog.No
one isallowedtotell the DevelopmentTeamtoworkfrom a differentsetof requirements,and
the DevelopmentTeamisn’tallowedtoacton whatanyone else says.

Page | 6
The Development Team
The DevelopmentTeam consistsof professionals whodothe work of deliveringapotentially
releasable Incrementof “Done”productat the endof each Sprint. Onlymembersof the
DevelopmentTeamcreate the Increment.
DevelopmentTeamsare structuredandempowered bythe organization toorganize and
manage theirownwork. The resultingsynergyoptimizesthe DevelopmentTeam’soverall
efficiencyandeffectiveness.
DevelopmentTeams have the followingcharacteristics:
 Theyare self-organizing.Noone (noteventhe ScrumMaster) tellsthe DevelopmentTeam
howto turn ProductBackloginto Incrementsof potentiallyreleasable functionality;
 DevelopmentTeamsare cross-functional,withall of the skills asa teamnecessarytocreate
a product Increment;
 Scrum recognizes notitlesforDevelopmentTeam members otherthanDeveloper,
regardlessof the workbeingperformedbythe person;there are noexceptionstothisrule;
 Scrum recognizesnosub-teamsinthe DevelopmentTeam, regardlessof particulardomains
that needtobe addressedliketestingorbusinessanalysis;thereare noexceptionstothis
rule;and,
 Individual DevelopmentTeammembersmayhave specializedskillsandareasof focus,but
accountability belongstothe DevelopmentTeamasa whole.
Development Team Size
Optimal DevelopmentTeamsize issmall enoughtoremainnimble andlarge enoughto
complete significantwork withinaSprint.Fewerthan three DevelopmentTeam members
decrease interactionandresultsinsmallerproductivitygains.SmallerDevelopmentTeams may
encounterskill constraintsduringthe Sprint,causingthe DevelopmentTeamtobe unable to
deliverapotentially releasableIncrement.Havingmore thannine members requires toomuch
coordination.Large DevelopmentTeamsgeneratetoomuchcomplexityforanempirical process
to manage. The ProductOwnerand ScrumMaster rolesare notincludedinthiscountunless
theyare also executingthe workof the SprintBacklog.
The Scrum Master
The Scrum Master is responsible forensuringScrumisunderstoodandenacted. ScrumMasters
do thisbyensuringthatthe Scrum Team adherestoScrum theory,practices,andrules.
The Scrum Master is a servant-leaderforthe ScrumTeam. The ScrumMaster helpsthose
outside the ScrumTeamunderstandwhichof theirinteractionswiththe ScrumTeamare helpful
and whicharen’t.The Scrum Master helpseveryone change theseinteractionstomaximize the
value createdbythe Scrum Team.

Page | 7
Scrum Master Service to the Product Owner
The Scrum Master serves the ProductOwnerinseveral ways,including:
 Findingtechniquesforeffective ProductBacklogmanagement;
 Helpingthe ScrumTeamunderstandthe needforclearand concise ProductBacklogitems;
 Understandingproductplanninginanempirical environment;
 Ensuringthe ProductOwnerknowshow to arrange the ProductBacklogto maximize value;
 Understandingand practicingagility;and,
 FacilitatingScrumeventsasrequestedorneeded.
Scrum Master Service to the Development Team
The Scrum Master serves the DevelopmentTeaminseveral ways,including:
 Coachingthe DevelopmentTeam inself-organizationandcross-functionality;
 Helpingthe DevelopmentTeamto create high-valueproducts;
 Removingimpedimentstothe DevelopmentTeam’sprogress;
 FacilitatingScrumeventsasrequestedorneeded;and,
 Coachingthe DevelopmentTeaminorganizational environments inwhich Scrumisnot yet
fullyadoptedandunderstood.
Scrum Master Service to the Organization
The Scrum Master serves the organizationinseveral ways,including:
 Leadingandcoachingthe organizationinitsScrumadoption;
 PlanningScrumimplementationswithin the organization;
 HelpingemployeesandstakeholdersunderstandandenactScrumand empirical product
development;
 Causingchange that increasesthe productivityof the ScrumTeam;and,
 WorkingwithotherScrum Mastersto increase the effectivenessof the applicationof Scrum
inthe organization.
Scrum Events
Prescribed eventsare usedinScrumto create regularityandto minimizethe needformeetings
not definedinScrum.All eventsare time-boxedevents,suchthateveryeventhasamaximum
duration.Once a Sprintbegins,itsdurationisfixedandcannotbe shortenedorlengthened.The
remainingeventsmayendwheneverthe purpose of the eventisachieved,ensuringan
appropriate amountof time isspentwithoutallowingwaste inthe process.
Otherthan the Sprintitself,whichisacontainerforall otherevents,eacheventinScrumisa
formal opportunitytoinspectandadapt something.These eventsare specificallydesignedto
enable critical transparencyandinspection. Failure toincludeanyof these eventsresultsin
reducedtransparency andisa lost opportunitytoinspect andadapt.

Page | 8
The Sprint
The heart of Scrum is a Sprint,a time-box of one monthorlessduringwhicha“Done”,useable,
and potentiallyreleasable productIncrementiscreated.Sprints besthave consistentdurations
throughouta developmenteffort.A new Sprintstartsimmediatelyafterthe conclusionof the
previousSprint.
Sprintscontainandconsistof the SprintPlanning,DailyScrums, the developmentwork,the
SprintReview,andthe SprintRetrospective.
Duringthe Sprint:
 No changesare made that would endangerthe SprintGoal;
 Qualitygoalsdonot decrease;and,
 Scope may be clarifiedandre-negotiatedbetweenthe ProductOwnerandDevelopment
Team as more islearned.
Each Sprintmay be consideredaproject withnomore than a one-monthhorizon.Like projects,
Sprintsare usedto accomplishsomething.EachSprinthasa definitionof whatistobe built,a
designand flexibleplanthatwill guide buildingit,the work, andthe resultantproduct.
Sprintsare limitedto one calendarmonth.Whena Sprint’shorizonistoolongthe definition of
whatis beingbuilt maychange, complexitymayrise,andriskmay increase.Sprintsenable
predictabilitybyensuringinspectionandadaptationof progresstowardaSprintGoal at least
everycalendarmonth. Sprintsalso limitrisktoone calendarmonth of cost.
Cancelling a Sprint
A Sprintcan be cancelledbefore the Sprinttime-box isover.Onlythe ProductOwnerhasthe
authoritytocancel the Sprint,althoughhe orshe may do so underinfluence fromthe
stakeholders,the DevelopmentTeam, orthe Scrum Master.
A Sprintwouldbe cancelledif the SprintGoal becomesobsolete.Thismightoccurif the
companychangesdirectionorif marketor technologyconditionschange.Ingeneral,aSprint
shouldbe cancelledif itnolongermakessense giventhe circumstances.But,due tothe short
durationof Sprints, cancellationrarelymakessense.
Whena Sprintis cancelled,anycompletedand“Done”ProductBacklogitemsare reviewed.If
part of the workis potentially releasable, the ProductOwnertypicallyacceptsit.All incomplete
ProductBacklog Itemsare re-estimatedandputback onthe ProductBacklog.The work done on
themdepreciatesquicklyandmustbe frequentlyre-estimated.
Sprintcancellationsconsumeresources,since everyone hastoregroupinanother Sprint
Planningtostart anotherSprint.Sprintcancellationsare oftentraumatictothe Scrum Team,
and are veryuncommon.

Page | 9
Sprint Planning
The work to be performedinthe Sprintisplannedatthe SprintPlanning.Thisplaniscreatedby
the collaborative workof the entire ScrumTeam.
SprintPlanningistime-boxedtoamaximumof eighthoursfora one-monthSprint. Forshorter
Sprints, the eventisusually shorter.The ScrumMasterensuresthatthe eventtakesplace and
that attendantsunderstanditspurpose.The ScrumMasterteachesthe ScrumTeam to keepit
withinthe time-box.
SprintPlanninganswersthe following:
 What can be deliveredinthe Incrementresultingfromthe upcomingSprint?
 How will the workneededtodeliverthe Incrementbe achieved?
Topic One: What can be done this Sprint?
The DevelopmentTeamworkstoforecastthe functionalitythatwillbe developedduringthe
Sprint.The ProductOwnerdiscusses the objective thatthe Sprintshouldachieve andthe
ProductBacklog itemsthat,if completed inthe Sprint, wouldachievethe SprintGoal.The entire
Scrum Teamcollaboratesonunderstandingthe workof the Sprint.
The inputto thismeetingisthe ProductBacklog,the latest productIncrement, projected
capacityof the DevelopmentTeamduringthe Sprint,andpastperformance of the Development
Team.The numberof itemsselectedfromthe ProductBacklog forthe Sprintis solelyuptothe
DevelopmentTeam.Onlythe DevelopmentTeamcanassesswhatit can accomplishoverthe
upcomingSprint.
Afterthe DevelopmentTeamforecasts the ProductBacklogitemsitwill deliverinthe Sprint,the
Scrum Teamcrafts a SprintGoal. The SprintGoal isan objective thatwill be met withinthe
Sprintthroughthe implementationof the ProductBacklog,andit providesguidance tothe
DevelopmentTeam onwhyitis buildingthe Increment.
Topic Two: How will the chosen work get done?
Havingsetthe SprintGoal and selectedthe ProductBacklogitemsforthe Sprint,the
DevelopmentTeamdecideshowitwill buildthisfunctionalityintoa“Done”productIncrement
duringthe Sprint.The ProductBacklog itemsselectedforthisSprintplusthe planfordelivering
themiscalledthe SprintBacklog.
The DevelopmentTeamusuallystartsbydesigningthe systemandthe work neededtoconvert
the Product Backloginto a workingproduct Increment.Workmaybe of varyingsize,or
estimatedeffort.However,enoughworkis planned duringSprintPlanningforthe Development
Team toforecastwhat itbelievesitcando inthe upcoming Sprint.Work planned forthe first
daysof the Sprintby the DevelopmentTeam isdecomposed bythe endof this meeting, oftento
unitsof one day or less. The DevelopmentTeamself-organizestoundertake the workinthe
SprintBacklog,bothduring SprintPlanningandasneededthroughoutthe Sprint.

Page | 10
The Product Ownercan help toclarifythe selected ProductBacklogitemsandmake trade-offs.
If the DevelopmentTeam determinesithastoomuch or toolittle work,itmayrenegotiate the
selectedProduct Backlogitemswiththe ProductOwner.The DevelopmentTeammayalsoinvite
otherpeople toattendinorderto provide technical ordomainadvice.
By the endof the SprintPlanning,the DevelopmentTeamshouldbe able toexplaintothe
ProductOwnerand Scrum Masterhow itintendstowork as a self-organizingteamto
accomplishthe SprintGoal and create the anticipated Increment.
Sprint Goal
The SprintGoal isan objective setforthe Sprintthatcan be metthroughthe implementationof
ProductBacklog.It providesguidance tothe DevelopmentTeamonwhyitis buildingthe
Increment.Itiscreatedduringthe SprintPlanningmeeting. The SprintGoal givesthe
DevelopmentTeamsome flexibilityregardingthe functionalityimplementedwithinthe Sprint.
The selectedProductBacklogitemsdeliverone coherentfunction,whichcanbe the SprintGoal.
The SprintGoal can be anyothercoherence thatcausesthe DevelopmentTeamtowork
togetherratherthanon separate initiatives.
As the DevelopmentTeamworks,itkeepsthe SprintGoal inmind.Inordertosatisfythe Sprint
Goal,it implementsthe functionalityandtechnology.If the workturnsoutto be differentthan
the DevelopmentTeamexpected,theycollaboratewiththe ProductOwnertonegotiate the
scope of SprintBacklogwithinthe Sprint.

Page | 11
Daily Scrum
The DailyScrum isa 15-minute time-boxedeventforthe DevelopmentTeam tosynchronize
activitiesand create aplan forthe next24 hours. This is done byinspectingthe worksince the
lastDailyScrum and forecastingthe workthatcouldbe done before the nextone.
The DailyScrum is heldat the same time and place eachday to reduce complexity. Duringthe
meeting, the DevelopmentTeammembersexplain:
 What didI do yesterdaythathelpedthe DevelopmentTeam meetthe SprintGoal?
 What will Ido todayto helpthe DevelopmentTeammeetthe Sprint Goal?
 Do I see anyimpedimentthatpreventsme orthe DevelopmentTeamfrommeetingthe
SprintGoal?
The DevelopmentTeam usesthe DailyScrumto inspectprogress towardthe SprintGoal andto
inspecthowprogressistrendingtowardcompletingthe workinthe SprintBacklog. The Daily
Scrum optimizesthe probabilitythatthe DevelopmentTeam will meetthe SprintGoal. Every
day,the DevelopmentTeamshould understandhow itintendstoworktogetherasa self-
organizingteamtoaccomplishthe SprintGoal and create the anticipated Incrementbythe end
of the Sprint. The DevelopmentTeamorteammembersoftenmeetimmediatelyafterthe Daily
Scrum fordetaileddiscussions,ortoadapt, or replan,the restof the Sprint’swork.
The Scrum Master ensuresthatthe DevelopmentTeam hasthe meeting,butthe Development
Team isresponsible forconductingthe DailyScrum.The ScrumMaster teachesthe
DevelopmentTeam tokeepthe DailyScrumwithinthe 15-minute time-box.
The Scrum Master enforcesthe rule that only DevelopmentTeam members participatein the
DailyScrum.
DailyScrumsimprove communications,eliminateothermeetings,identifyimpedimentsto
developmentforremoval,highlightandpromote quick decision-making,andimprove the
DevelopmentTeam’slevelof knowledge. Thisisakeyinspectandadapt meeting.
Sprint Review
A SprintReview isheld atthe endof the Sprint to inspectthe Incrementandadaptthe Product
Backlogif needed.Duringthe SprintReview,the ScrumTeamandstakeholderscollaborate
aboutwhat was done in the Sprint.Basedonthat and any changesto the ProductBacklog
duringthe Sprint,attendeescollaborate onthe nextthingsthatcouldbe done tooptimize value.
Thisis an informal meeting, notastatusmeeting, andthe presentationof the Incrementis
intendedto elicitfeedbackandfostercollaboration.
Thisis a four-hourtime-boxedmeetingforone-monthSprints. ForshorterSprints,the eventis
usuallyshorter.The ScrumMaster ensuresthatthe eventtakesplace andthat attendants
understanditspurpose.The ScrumMaster teachesall tokeepitwithinthe time-box.

Page | 12
The SprintReview includesthe followingelements:
 Attendees includethe ScrumTeamand keystakeholdersinvitedbythe ProductOwner;
 The Product Ownerexplains whatProductBacklogitems have been“Done”andwhathas
not been“Done”;
 The DevelopmentTeam discusseswhatwentwell duringthe Sprint,whatproblemsit ran
into,andhow those problems were solved;
 The DevelopmentTeam demonstratesthe workthat ithas “Done” andanswersquestions
aboutthe Increment;
 The Product Ownerdiscussesthe ProductBacklogasitstands.He or she projectslikely
completiondates basedonprogresstodate (if needed);
 The entire group collaborates onwhatto do next,sothatthe SprintReview provides
valuable inputtosubsequent SprintPlanning;
 Reviewof howthe marketplace orpotential use of the productmighthave changedwhat is
the most valuable thingtodo next;and,
 Reviewof the timeline,budget, potential capabilities,andmarketplace for the next
anticipatedrelease of the product.
The resultof the SprintReviewisarevisedProductBacklogthatdefinesthe probable Product
Backlogitemsforthe nextSprint.The ProductBacklog mayalso be adjustedoverall tomeetnew
opportunities.
Sprint Retrospective
The SprintRetrospective isanopportunityforthe ScrumTeamto inspectitself andcreate aplan
for improvementstobe enactedduringthe nextSprint.
The SprintRetrospective occursafterthe SprintReview andpriortothe next SprintPlanning.
Thisis a three-hourtime-boxedmeetingforone-monthSprints. ForshorterSprints,the eventis
usuallyshorter.The ScrumMaster ensuresthatthe eventtakesplace andthat attendants
understanditspurpose.The ScrumMaster teachesall tokeepitwithinthe time-box.The Scrum
Master participatesasa peerteammemberinthe meetingfromthe accountabilityoverthe
Scrum process.
The purpose of the SprintRetrospective isto:
 Inspecthowthe lastSprintwent withregardsto people,relationships,process,andtools;
 Identifyand orderthe majoritemsthatwentwell and potential improvements;and,
 Create a planfor implementingimprovementstothe waythe ScrumTeam doesitswork.

Page | 13
The Scrum Master encouragesthe ScrumTeam to improve,withinthe Scrumprocess
framework,itsdevelopmentprocess andpractices tomake it more effectiveandenjoyable for
the nextSprint. DuringeachSprintRetrospective,the ScrumTeamplansways to increase
productqualityby adaptingthe definitionof “Done”asappropriate.
By the endof the SprintRetrospective,the ScrumTeamshouldhave identifiedimprovements
that itwill implementinthe nextSprint. Implementingthese improvements inthe nextSprint is
the adaptationto the inspection of the ScrumTeamitself.Althoughimprovementsmaybe
implementedatanytime,the Sprint Retrospectiveprovidesaformal opportunityto focuson
inspectionandadaptation.
Scrum Artifacts
Scrum’sartifactsrepresentworkorvalue to provide transparencyandopportunitiesfor
inspectionandadaptation. ArtifactsdefinedbyScrumare specificallydesignedtomaximize
transparencyof keyinformation sothateverybodyhasthe same understandingof the artifact.
Product Backlog
The Product Backlogisan ordered listof everythingthatmightbe neededinthe product andis
the single source of requirementsfor anychangestobe made to the product.The Product
Ownerisresponsibleforthe ProductBacklog, includingitscontent,availability,andordering.
A ProductBacklogis nevercomplete.The earliestdevelopmentof itonlylaysoutthe initially
knownandbest-understoodrequirements.The ProductBacklogevolvesasthe productand the
environmentinwhichitwill be usedevolves.The ProductBacklogisdynamic;itconstantly
changesto identifywhatthe productneedstobe appropriate,competitive,anduseful.Aslong
as a product exists, itsProductBacklogalsoexists.
The Product Backloglistsall features,functions, requirements,enhancements, andfixesthat
constitute the changes tobe made to the product infuture releases. ProductBacklogitemshave
the attributesof a description, order,estimate andvalue.
As a productis used andgains value,andthe marketplace providesfeedback,the Product
Backlogbecomes a largerand more exhaustive list.Requirementsneverstopchanging,soa
ProductBacklog isa living artifact.Changesinbusinessrequirements,marketconditions, or
technology maycause changesinthe ProductBacklog.
Multiple ScrumTeamsoftenworktogetheronthe same product.One ProductBacklogis used
to describe the upcomingworkonthe product.A ProductBacklogattribute thatgroups items
may thenbe employed.

Page | 14
ProductBacklog refinementisthe actof addingdetail,estimates,and ordertoitemsinthe
ProductBacklog.Thisis an ongoingprocess inwhich the ProductOwnerandthe Development
Team collaborate onthe detailsof ProductBacklogitems.DuringProductBacklog refinement,
itemsare reviewedandrevised. The ScrumTeamdecideshow andwhenrefinementisdone.
Refinementusuallyconsumesnomore than10% of the capacity of the DevelopmentTeam.
However, ProductBacklogitems canbe updatedat any time bythe ProductOwneror at the
ProductOwner’sdiscretion.
HigherorderedProductBacklogitemsare usually clearerandmore detailedthanlowerordered
ones.More precise estimatesare made basedonthe greaterclarityandincreaseddetail;the
lowerthe order,the lessdetail.ProductBacklogitemsthatwill occupythe DevelopmentTeam
for the upcomingSprintare refinedsothatany one itemcan reasonably be “Done”withinthe
Sprinttime-box.ProductBacklogitemsthatcan be “Done”by the DevelopmentTeamwithin
one Sprintare deemed“Ready”forselectionina SprintPlanning.ProductBacklogitemsusually
acquire thisdegree of transparencythroughthe above describedrefiningactivities.
The DevelopmentTeam isresponsible forall estimates.The ProductOwnermayinfluence the
DevelopmentTeam byhelpingitunderstandandselecttrade-offs,butthe peoplewhowill
performthe workmake the final estimate.
Monitoring Progress Toward a Goal
At anypointin time,the total workremaining toreacha goal can be summed. The Product
Ownertracks thistotal workremainingatleasteverySprintReview.The ProductOwner
comparesthisamountwithworkremainingatpreviousSprintReviewstoassessprogress
towardcompletingprojectedworkbythe desiredtime forthe goal.Thisinformationismade
transparentto all stakeholders.
Variousprojectivepractices upontrendinghave beenusedtoforecastprogress,like burn-
downs, burn-ups,orcumulative flows.These have provenuseful.However,these donotreplace
the importance of empiricism. Incomplex environments,whatwillhappenisunknown.Only
whathas happenedmaybe usedforforward-lookingdecision-making.
Sprint Backlog
The SprintBacklog isthe set of ProductBacklog itemsselectedforthe Sprint,plusaplanfor
deliveringthe productIncrement andrealizingthe SprintGoal.The SprintBacklogisa forecast
by the DevelopmentTeam aboutwhatfunctionalitywill be inthe nextIncrementandthe work
neededtodeliverthatfunctionality intoa“Done”Increment.
The SprintBacklog makesvisibleall of the workthatthe DevelopmentTeam identifiesas
necessarytomeetthe Sprint Goal.

Page | 15
The SprintBacklog isa planwith enoughdetail thatchangesinprogresscan be understoodin
the DailyScrum. The DevelopmentTeam modifies the SprintBacklogthroughoutthe Sprint, and
the SprintBacklogemergesduringthe Sprint. Thisemergence occursas the DevelopmentTeam
works throughthe plan andlearns more about the work needed toachieve the SprintGoal.
As newworkisrequired,the DevelopmentTeam addsitto the SprintBacklog. Asworkis
performedorcompleted,the estimatedremainingworkisupdated. Whenelementsof the plan
are deemedunnecessary,theyare removed.Onlythe DevelopmentTeam canchange its Sprint
Backlogduringa Sprint.The SprintBacklog isa highlyvisible,real-time pictureof the workthat
the DevelopmentTeam planstoaccomplishduringthe Sprint,anditbelongssolelytothe
DevelopmentTeam.
Monitoring Sprint Progress
At anypointin time ina Sprint,the total workremaininginthe SprintBacklogcan be summed.
The DevelopmentTeamtracksthistotal work remainingatleastforeveryDailyScrum to project
the likelihoodof achievingthe SprintGoal.Bytrackingthe remainingworkthroughoutthe
Sprint,the DevelopmentTeamcanmanage itsprogress.
Increment
The Incrementisthe sum of all the Product BacklogitemscompletedduringaSprintand the
value of the incrementsof all previous Sprints. Atthe endof a Sprint,the new Incrementmust
be “Done,”whichmeansit mustbe in useable condition andmeetthe ScrumTeam’s definition
of “Done.”It mustbe in useable conditionregardlessof whether the ProductOwnerdecidesto
actuallyrelease it.
Artifact Transparency
Scrum reliesontransparency.Decisionstooptimize valueandcontrol riskare made basedon
the perceivedstate of the artifacts. Tothe extentthattransparencyiscomplete,these decisions
have a soundbasis. To the extentthatthe artifactsare incompletelytransparent,these
decisionscanbe flawed,valuemaydiminish andrisk mayincrease.
The Scrum Master must workwiththe ProductOwner,DevelopmentTeam, andotherinvolved
partiestounderstand if the artifactsare completelytransparent.There are practicesforcoping
withincompletetransparency;the ScrumMastermusthelpeveryone applythe most
appropriate practices inthe absence of complete transparency.A ScrumMaster can detect
incomplete transparencyby inspectingthe artifacts, sensingpatterns,listeningcloselytowhatis
beingsaid,anddetectingdifferencesbetweenexpectedandreal results.
The Scrum Master’s jobisto work withthe Scrum Teamand the organizationtoincrease the
transparencyof the artifacts.Thiswork usuallyinvolves learning,convincing,andchange.
Transparencydoesn’toccurovernight,butisa path.

Page | 16
Definitionof “Done”
Whena Product Backlogitemor an Incrementisdescribedas “Done”,everyone must
understandwhat“Done”means.Althoughthisvariessignificantly perScrumTeam, members
musthave a sharedunderstandingof whatitmeansfor workto be complete,toensure
transparency.Thisisthe definitionof “Done”forthe Scrum Teamand isusedto assesswhen
workis complete onthe productIncrement.
The same definitionguidesthe DevelopmentTeaminknowinghow manyProductBacklogitems
it can selectduringaSprintPlanning.The purpose of eachSprintisto deliverIncrementsof
potentiallyreleasable functionalitythatadhere tothe Scrum Team’scurrentdefinitionof
“Done.”
DevelopmentTeamsdeliveranIncrementof productfunctionalityeverySprint.ThisIncrement
isuseable,soa ProductOwnermaychoose to immediatelyreleaseit. If the definitionof "done"
for an increment ispartof the conventions,standardsorguidelinesof the development
organization,all ScrumTeamsmustfollow itasa minimum.If "done"foran incrementis nota
conventionof the developmentorganization,the DevelopmentTeamof the Scrum Teammust
define adefinitionof “done”appropriate forthe product.If there are multiple ScrumTeams
workingonthe systemor productrelease,the development teamsonall of the Scrum Teams
mustmutuallydefinethe definitionof “Done.”
Each Incrementisadditive to all priorIncrementsandthoroughlytested,ensuringthatall
Incrementsworktogether.
As ScrumTeams mature,itisexpectedthattheirdefinitionsof “Done”will expandtoinclude
more stringentcriteriaforhigherquality. Anyone productorsystemshouldhave adefinitionof
“Done”that is a standardfor any workdone on it.
End Note
Scrum isfree and offeredinthis Guide.Scrum’sroles, artifacts, events,andrulesare immutable
and althoughimplementingonlypartsof Scrum ispossible,the resultis notScrum.Scrum exists
onlyinits entiretyandfunctionswell asacontainerforothertechniques,methodologies,and
practices.

Page | 17
Acknowledgements
People
Of the thousandsof people whohave contributedtoScrum, we shouldsingle outthose who
were instrumentalinitsfirsttenyears.Firstthere wasJeff Sutherland workingwithJeff
McKenna,and KenSchwaber workingwithMike SmithandChrisMartin. Many others
contributedinthe ensuingyearsand withouttheirhelpScrumwould notbe refinedasitis
today.
History
KenSchwaberandJeff Sutherlandfirstco-presentedScrumatthe OOPSLA conference in1995.
Thispresentationessentiallydocumentedthe learningthatKenandJeff gainedoverthe
previousfewyearsapplyingScrum.
The historyof Scrumis alreadyconsideredlong.Tohonorthe firstplaceswhere itwastriedand
refined,we recognize Individual,Inc.,FidelityInvestments,andIDX(now GE Medical).
The Scrum Guide documentsScrumas developedandsustainedfor 20-plusyearsbyJeff
SutherlandandKenSchwaber. Othersourcesprovideyouwithpatterns,processes,andinsights
that complementthe Scrumframework.Theseoptimizeproductivity,value,creativity,and
pride.

2016 scrum-guide-us

Recommended

Recommended

More Related Content

Similar to 2016 scrum-guide-us

Similar to 2016 scrum-guide-us (20)

Recently uploaded

Recently uploaded (20)

2016 scrum-guide-us