Transcription
Purpose of the Scrum GuideWe developed Scrum in the early 1990s. We wrote the firstversion of the Scrum Guide in 2010 to help people worldwideunderstand Scrum. We have evolved the Guide since thenthrough small, functional updates. Together, we standbehind it.The Scrum Guide contains the definition of Scrum.Each element of the framework serves a specific purposethat is essential to the overall value and results realized withScrum. Changing the core design or ideas of Scrum, leavingout elements, or not following the rules of Scrum, covers upproblems and limits the benefits of Scrum, potentially evenrendering it useless.Jeff SutherlandKen Schwaber1
We follow the growing use of Scrum within an ever-growingcomplex world. We are humbled to see Scrum being adoptedin many domains holding essentially complex work, beyondsoftware product development where Scrum has its roots.As Scrum’s use spreads, developers, researchers, analysts,scientists, and other specialists do the work. We use the word“developers” in Scrum not to exclude, but to simplify.If you get value from Scrum, consider yourself included.DeveloperAs Scrum is being used, patterns, processes, and insights thatfit the Scrum framework as described in this document, maybe found, applied and devised. Their description is beyondthe purpose of the Scrum Guide because they are contextsensitive and differ widely between Scrum uses. Such tacticsfor using within the Scrum framework vary widely and aredescribed elsewhere.Ken Schwaber & Jeff Sutherland July 20202
2020 Ken Schwaber and Jeff SutherlandThis publication is offered for license under the AttributionShare-Alike license of Creative Commons, accessible at lcode and alsodescribed in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, youacknowledge and agree that you have read and agree to bebound by the terms of the Attribution Share-Alikelicense of Creative Commons. 2020 Kate Hobler (Terlecka)Original work: “Scrum ges made from Scrum Guide: Added Illustrations3
Purpose of the Scrum Guide . . . 1Scrum Definition . . . . . . . . . . . . 7Scrum Theory . . . . . . . . . . . . . . 9Transparency . . . . . . . . . . . . . . . . . . . . 9Inspection . . . . . . . . . . . . . . . . . . . . . . 10Adaptation . . . . . . . . . . . . . . . . . . . . . . 10Scrum Values . . . . . . . . . . . . . . . 11Scrum Team . . . . . . . . . . . . . . . . 12Developers . . . . . . . . . . . . . . . . . . . . . . 13Product Owner . . . . . . . . . . . . . . . . . . 14Scrum Master . . . . . . . . . . . . . . . . . . . 15Scrum Events . . . . . . . . . . . . . . . 18The Sprint . . . . . . . . .Sprint Planning . . . . .Daily Scrum . . . . . . . .Sprint Review . . . . . .Sprint Retrospective . 18. 20. 22. 23. 24Scrum Artifacts . . . . . . . . . . . .25Product Backlog . . . . . . . . . . . . . . . . 25Commitment: Product Goal . . . . . . . . . . . . . . . . 25Sprint Backlog . . . . . . . . . . . . . . . . . . 27Commitment: Sprint Goal . . . . . . . . . . . . . . . . . . 28Increment . . . . . . . . . . . . . . . . . . . . . . 29Commitment: Definition of Done . . . . . . . . . . . . . 30End Note . . . . . . . . . . . . . . . . . . 31Acknowledgements . . . . . . . . . . . . . . . 32People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Scrum Guide History . . . . . . . . . . . . . . . . . . . . . . 325
Scrum DefinitionScrum is a lightweight framework that helps people,teams and organizations generate value throughadaptive solutions for complex problems.In a nutshell, Scrum requires a Scrum Master to fosteran environment where:1 . A Product Owner orders the work for a complexproblem into a Product Backlog.2 . The Scrum Team turns a selection of the work intoan Increment of value during a Sprint.3 . The Scrum Team and its stakeholders inspect theresults and adjust for the next Sprint.4 . Repeat7
Scrum is simple. Try it as is and determine if itsphilosophy, theory, and structure help to achievegoals and create value. The Scrum framework ispurposefully incomplete, only defining the partsrequired to implement Scrum theory.Scrum is built upon by the collective intelligenceof the people using it. Rather than provide peoplewith detailed instructions, the rules of Scrumguide their relationships and interactions.Various processes, techniques and methodscan be employed within the framework. Scrumwraps around existing practices or rendersthem unnecessary. Scrum makes visible therelative efficacy of current management,environment, and work techniques, so thatimprovements can be made.8
Scrum TheoryScrum is founded on empiricism and leanthinking. Empiricism asserts that knowledgecomes from experience and making decisionsbased on what is observed. Lean thinkingreduces waste and focuses on the essentials.Scrum employs an iterative, incrementalapproach to optimize predictability and tocontrol risk. Scrum engages groups of peoplewho collectively have all the skills and expertiseto do the work and share or acquire such skillsas needed.Scrum combines four formal events forinspection and adaptation within a containingevent, the Sprint. These events work becausethey implement the empirical Scrum pillarsof transparency, inspection, and adaptation.TransparencyThe emergent process and work must be visibleto those performing the work as well as thosereceiving the work. With Scrum, importantdecisions are based on the perceived state ofits three formal artifacts. Artifacts that have lowtransparency can lead to decisions that diminishvalue and increase risk.Transparency enables inspection. Inspectionwithout transparency is misleading and wasteful.9
InspectionThe Scrum artifacts and the progress towardagreed goals must be inspected frequentlyand diligently to detect potentially undesirablevariances or problems. To help with inspection,Scrum provides cadence in the form of itsfive events.Inspection enables adaptation. Inspectionwithout adaptation is considered pointless.Scrum events are designed to provoke change.AdaptationIf any aspects of a process deviate outsideacceptable limits or if the resulting product isunacceptable, the process being applied or thematerials being produced must be adjusted.The adjustment must be made as soon aspossible to minimize further deviation.Adaptation becomes more difficult whenthe people involved are not empowered orself-managing. A Scrum Team is expectedto adapt the moment it learns anything newthrough inspection.10
Scrum ValuesSuccessful use of Scrum depends on peoplebecoming more proficient in living five values:Commitment, Focus, Openness, Respect, and CourageThe Scrum Team commits to achieving its goals andto supporting each other. Their primary focus is onthe work of the Sprint to make the best possibleprogress toward these goals. The Scrum Team andits stakeholders are open about the work and thechallenges. Scrum Team members respect eachother to be capable, independent people, and arerespected as such by the people with whom theywork. The Scrum Team members have the courageto do the right thing, to work on tough problems.These values give direction to the Scrum Team withregard to their work, actions, and behavior. Thedecisions that are made, the steps taken, and theway Scrum is used should reinforce these values,not diminish or undermine them. The Scrum Teammembers learn and explore the values as they workwith the Scrum events and artifacts. When thesevalues are embodied by the Scrum Team and thepeople they work with, the empirical Scrum pillarsof transparency, inspection, and adaptation cometo life building trust.11
Scrum TeamThe fundamental unit of Scrum is a small team of people,a Scrum Team. The Scrum Team consists of one ScrumMaster, one Product Owner, and Developers. Withina Scrum Team, there are no sub-teams or hierarchies.It is a cohesive unit of professionals focused on oneobjective at a time, the Product Goal.Scrum Teams are cross-functional, meaning the membershave all the skills necessary to create value each Sprint.They are also self-managing, meaning they internallydecide who does what, when, and how.The Scrum Team is small enough to remain nimble andlarge enough to complete significant work within a Sprint,typically 10 or fewer people. In general, we have foundthat smaller teams communicate better and are moreproductive. If Scrum Teams become too large, theyshould consider reorganizing into multiple cohesiveScrum Teams, each focused on the same product.Therefore, they should share the same Product Goal,Product Backlog, and Product Owner.The Scrum Team is responsible for all product-relatedactivities from stakeholder collaboration, verification,maintenance, operation, experimentation, research anddevelopment, and anything else that might be required.They are structured and empowered by the organizationto manage their own work. Working in Sprints ata sustainable pace improves the Scrum Team’s focusand consistency.12
The entire Scrum Team is accountable for creatinga valuable, useful Increment every Sprint. Scrum definesthree specific accountabilities within the Scrum Team:the Developers, the Product Owner, and the Scrum Master.DevelopersDevelopers are the people in the Scrum Team that arecommitted to creating any aspect of a usable Incrementeach Sprint.The specific skills needed by the Developers are oftenbroad and will vary with the domain of work. However,the Developers are always accountable for: Creating a plan for the Sprint, the Sprint Backlog; Holding each other accountable as professionals.Instilling quality by adhering to a Definition of Done;Adapting their plan each day toward the Sprint Goal;and,13
Product OwnerThe Product Owner is accountable for maximizing thevalue of the product resulting from the work of theScrum Team. How this is done may vary widely acrossorganizations, Scrum Teams, and individuals.The Product Owner is also accountable for effectiveProduct Backlog management, which includes: Developing and explicitly communicating theProduct Goal; Creating and clearly communicating ProductBacklog items; Ordering Product Backlog items;and, Ensuring that the Product Backlog is transparent,visible and understood.The Product Owner may do the above work or maydelegate the responsibility to others. Regardless, theProduct Owner remains accountable.For Product Owners to succeed, the entire organizationmust respect their decisions. These decisions are visiblein the content and ordering of the Product Backlog, andthrough the inspectable Increment at the Sprint Review.The Product Owner is one person, not a committee.The Product Owner may represent the needs of manystakeholders in the Product Backlog. Those wantingto change the Product Backlog can do so by trying toconvince the Product Owner.14
Scrum MasterThe Scrum Master is accountable for establishing Scrumas defined in the Scrum Guide. They do this by helpingeveryone understand Scrum theory and practice, bothwithin the Scrum Team and the organization.The Scrum Master is accountable for the Scrum Team’seffectiveness. They do this by enabling the Scrum Teamto improve its practices, within the Scrum framework.Scrum Masters are true leaders who serve the ScrumTeam and the larger organization. The Scrum Masterserves the Scrum Team in several ways, including: Coaching the team members in self-management andcross-functionality; Helping the Scrum Team focus on creating high-valueIncrements that meet the Definition of Done; Causing the removal of impediments to the ScrumTeam’s progress;and, Ensuring that all Scrum events take place and arepositive, productive, and kept within the timebox.15
The Scrum Master serves the Product Owner in severalways, including: Helping find techniques for effective Product Goaldefinition and Product Backlog management; Helping the Scrum Team understand the need forclear and concise Product Backlog items; Helping establish empirical product planning fora complex environment;and, Facilitating stakeholder collaboration as requestedor needed.16
The Scrum Master serves the organization inseveral ways, including: Leading, training, and coaching the organizationin its Scrum adoption; Planning and advising Scrum implementationswithin the organization; Helping employees and stakeholdersunderstand and enact an empirical approachfor complex work;and, Removing barriers between stakeholders andScrum Teams.17
Scrum EventsThe Sprint is a container for all other events. Each eventin Scrum is a formal opportunity to inspect and adaptScrum artifacts. These events are specifically designedto enable the transparency required. Failure to operateany events as prescribed results in lost opportunities toinspect and adapt. Events are used in Scrum to createregularity and to minimize the need for meetings notdefined in Scrum. Optimally, all events are held at thesame time and place to reduce complexity.The SprintSprints are the heartbeat of Scrum, where ideasare turned into value.They are fixed length events of one monthor less to create consistency. A new Sprintstarts immediately after the conclusion of theprevious Sprint.All the work necessary to achieve the ProductGoal, including Sprint Planning, Daily Scrums,Sprint Review, and Sprint Retrospective, happenwithin Sprints.18
During the Sprint: No changes are made that would endangerthe Sprint Goal; Quality does not decrease; Scope may be clarified and renegotiatedwith the Product Owner as more is learned.The Product Backlog is refined as needed;and,Sprints enable predictability by ensuringinspection and adaptation of progress towarda Product Goal at least every calendar month.When a Sprint’s horizon is too long the SprintGoal may become invalid, complexity may rise,and risk may increase. Shorter Sprints can beemployed to generate more learning cyclesand limit risk of cost and effort to a smallertime frame. Each Sprint may be considereda short project.Various practices exist to forecast progress,like burn-downs, burn-ups, or cumulativeflows. While proven useful, these do notreplace the importance of empiricism. Incomplex environments, what will happenis unknown. Only what has alreadyhappened may be used for forward-lookingdecision making.A Sprint could be cancelled if the Sprint Goalbecomes obsolete. Only the Product Ownerhas the authority to cancel the Sprint.19
Sprint PlanningSprint Planning initiates the Sprint by laying out thework to be performed for the Sprint. This resultingplan is created by the collaborative work of the entireScrum Team.The Product Owner ensures that attendees are preparedto discuss the most important Product Backlog items andhow they map to the Product Goal. The Scrum Team mayalso invite other people to attend Sprint Planningto provide advice.Sprint Planning addresses the following topics:Topic One: Why is this Sprint valuable?The Product Owner proposes how the product couldincrease its value and utility in the current Sprint. Thewhole Scrum Team then collaborates to define a SprintGoal that communicates why the Sprint is valuable tostakeholders. The Sprint Goal must be finalized priorto the end of Sprint Planning.20
Topic Two: What can be Done this Sprint?Through discussion with the Product Owner, theDevelopers select items from the Product Backlogto include in the current Sprint. The Scrum Teammay refine these items during this process, whichincreases understanding and confidence.Selecting how much can be completed withina Sprint may be challenging. However, the more theDevelopers know about their past performance,their upcoming capacity, and their Definition ofDone, the more confident they will be in their Sprintforecasts.Topic Three: How will the chosen work get done?For each selected Product Backlog item, theDevelopers plan the work necessary to createan Increment that meets the Definition of Done.This is often done by decomposing Product Backlogitems into smaller work items of one day or less.How this is done is at the sole discretion of theDevelopers. No one else tells them how to turnProduct Backlog items into Increments of value.The Sprint Goal, the Product Backlog items selectedfor the Sprint, plus the plan for delivering them aretogether referred to as the Sprint Backlog.Sprint Planning is timeboxed to a maximum of eighthours for a one-month Sprint. For shorter Sprints,the event is usually shorter.21
Daily ScrumThe purpose of the Daily Scrum is to inspect progresstoward the Sprint Goal and adapt the Sprint Backlog asnecessary, adjusting the upcoming planned work.The Daily Scrum is a 15-minute event for the Developersof the Scrum Team. To reduce complexity, it is held at thesame time and place every working day ofthe Sprint. If the Product Owner or Scrum Master areactively working on items in the Sprint Backlog,they participate as Developers.The Developers can select whatever structure andtechniques they want, as long as their Daily Scrumfocuses on progress toward the Sprint Goal and producesan actionable plan for the next day of work. This createsfocus and improves self-management.Daily Scrums improve communications, identifyimpediments, promote quick decision-making, andconsequently eliminate the need for other meetings.The Daily Scrum is not the only time Developers areallowed to adjust their plan. They often meet throughoutthe day for more detailed discussions about adapting orre-planning the rest of the Sprint’s work.22
Sprint ReviewThe purpose of the Sprint Review is to inspectthe outcome of the Sprint and determine futureadaptations. The Scrum Team presents the resultsof their work to key stakeholders and progresstoward the Product Goal is discussed.During the event, the Scrum Team andstakeholders review what was accomplished in theSprint and what has changed in their environment.Based on this information, attendees collaborateon what to do next. The Product Backlog may alsobe adjusted to meet new opportunities. The SprintReview is a working session and the Scrum Teamshould avoid limiting it to a presentation.The Sprint Review is the second to last event ofthe Sprint and is timeboxed to a maximum of fourhours for a one-month Sprint. For shorter Sprints,the event is usually shorter.23
Sprint RetrospectiveThe purpose of the Sprint Retrospective is to planways to increase quality and effectiveness.The Scrum Team inspects how the last Sprint wentwith regards to individuals, interactions, processes,tools, and their Definition of Done. Inspectedelements often vary with the domain of work.Assumptions that led them astray are identifiedand their origins explored. The Scrum Teamdiscusses what went well during the Sprint, whatproblems it encountered, and how those problemswere (or were not) solved.The Scrum Team identifies the most helpfulchanges to improve its effectiveness. The mostimpactful improvements are addressed as soonas possible. They may even be added to the SprintBacklog for the next Sprint.The Sprint Retrospective concludes the Sprint. It istimeboxed to a maximum of three hours for a onemonth Sprint. For shorter Sprints, the event isusually shorter.24
Scrum ArtifactsScrum’s artifacts represent work or value. Theyare designed to maximize transparency of keyinformation. Thus, everyone inspecting them hasthe same basis for adaptation.Each artifact contains a commitment toensure it provides information that enhancestransparency and focus against which progresscan be measured: For the Product Backlog it is the Product Goal.For the Sprint Backlog it is the Sprint Goal.For the Increment it is the Definition of Done.These commitments exist to reinforceempiricism and the Scrum values for the ScrumTeam and their stakeholders.Product BacklogCommitment: Product GoalThe Product Backlog is an emergent, ordered list of whatis needed to improve the product. It is the single sourceof work undertaken by the Scrum Team.Product Backlog items that can be Done by the ScrumTeam within one Sprint are deemed ready for selectionin a Sprint Planning event. They usually acquire thisdegree of transparency after refining activities. ProductBacklog refinement is the act of breaking down andfurther defining Product Backlog items into smallermore precise items. This is an ongoing activity to adddetails, such as a description, order, and size. Attributesoften vary with the domain of work.25
The Developers who will be doing the work areresponsible for the sizing. The Product Owner mayinfluence the Developers by helping them understandand select trade-offs.The Product Goal describes a future state of theproduct which can serve as a target for the Scrum Teamto plan against. The Product Goal is in the ProductBacklog. The rest of the Product Backlog emerges todefine “what” will fulfill the Product Goal.A product is a vehicle to deliver value. It has a clearboundary, known stakeholders, well-defined users orcustomers. A product could be a service, a physicalproduct, or something more abstract.The Product Goal is the long-term objective for theScrum Team. They must fulfill (or abandon) oneobjective before taking on the next.26
Sprint BacklogThe Sprint Backlog is composed of the Sprint Goal(why), the set of Product Backlog items selectedfor the Sprint (what), as well as an actionable planfor delivering the Increment (how).The Sprint Backlog is a plan by and for theDevelopers. It is a highly visible, real-timepicture of the work that the Developers plan toaccomplish during the Sprint in order to achievethe Sprint Goal.Consequently, the Sprint Backlog is updatedthroughout the Sprint as more is learned.It should have enough detail that they can inspecttheir progress in the Daily Scrum.27
Commitment: Sprint GoalThe Sprint Goal is the single objective for the Sprint.Although the Sprint Goal is a commitment by theDevelopers, it provides flexibility in terms of theexact work needed to achieve it. The Sprint Goalalso creates coherence and focus, encouragingthe Scrum Team to work together rather than onseparate initiatives.The Sprint Goal is created during the Sprint Planningevent and then added to the Sprint Backlog. Asthe Developers work during the Sprint, they keepthe Sprint Goal in mind. If the work turns out to bedifferent than they expected, they collaborate withthe Product Owner to negotiate the scope of theSprint Backlog within the Sprint without affecting theSprint Goal.28
IncrementAn Increment is a concrete stepping stone toward theProduct Goal. Each Increment is additive to all priorIncrements and thoroughly verified, ensuring that allIncrements work together. In order to provide value,the Increment must be usable.Multiple Increments may be created within a Sprint.The sum of the Increments is presented at theSprint Review thus supporting empiricism. However,an Increment may be delivered to stakeholders priorto the end of the Sprint. The Sprint Review shouldnever be considered a gate to releasing value.Work cannot be considered part of an Incrementunless it meets the Definition of Done.29
Commitment: Definition of DoneThe Definition of Done is a formal descriptionof the state of the Increment when it meets thequality measures required for the product.The moment a Product Backlog item meets theDefinition of Done, an Increment is born.The Definition of Done creates transparencyby providing everyone a shared understandingof what work was completed as part of theIncrement. If a Product Backlog item doesnot meet the Definition of Done, it cannot bereleased or even presented at the Sprint Review.Instead, it returns to the Product Backlog forfuture consideration.If the Definition of Done for an increment ispart of the standards of the organization, allScrum Teams must follow it as a minimum.If it is not an organizational standard, theScrum Team must create a Definition of Doneappropriate for the product.The Developers are required to conform tothe Definition of Done. If there are multipleScrum Teams working together on a product,they must mutually define and comply with thesame Definition of Done.30
End NoteScrum is free and offered in this Guide. The Scrum framework,as outlined herein, is immutable. While implementing onlyparts of Scrum is possible, the result is not Scrum. Scrum existsonly in its entirety and functions well as a container for othertechniques, methodologies, and practices.31
AcknowledgementsPeopleScrum is free and offered in this Guide. The Scrumframework, as outlined herein, is immutable. Whileimplementing only parts of Scrum is possible, the result isnot Scrum. Scrum exists only in its entirety and functionswell as a container for other techniques, methodologies,and practices.Scrum Guide HistoryKen Schwaber and Jeff Sutherland first co-presentedScrum at the OOPSLA Conference in 1995. It essentiallydocumented the learning that Ken and Jeff gained overthe previous few years and made public the first formaldefinition of Scrum.The Scrum Guide documents Scrum as developed,evolved, and sustained for 30-plus years by Jeff Sutherlandand Ken Schwaber. Other sources provide patterns,processes, and insights that complement the Scrumframework. These may increase productivity, value,creativity, and satisfaction with the results.The complete history of Scrum is described elsewhere.To honor the first places where it was tried and proven,we recognize Individual Inc., Newspage, FidelityInvestments, and IDX (now GE Medical).32
We developed Scrum in the early 1990s. We wrote the irst version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it. The Scrum Guide contains the deinition of Scrum
