Purpose of this Scrum Guide
Scrum, an agile framework, was first conceived in the early 1990s. To ensure a globally consistent understanding of its principles, the initial Scrum Guide was published in 2010. Since then, this guide has been iteratively refined through minor, functional updates, always with the collective endorsement of its creators.
This Scrum Guide serves as the definitive reference for Scrum. Each element within the Scrum framework is purposefully designed to contribute to the overall value and effective outcomes of using Scrum. Deviating from Scrum’s core structure, omitting components, or disregarding its rules can obscure underlying issues and diminish, or even nullify, its potential benefits.
Scrum’s adaptability is evident in its expanding application across diverse and increasingly complex sectors, extending beyond its origins in software development. While Scrum’s principles are applied by a wide range of professionals—developers, researchers, analysts, and scientists—the term “developers” is used in this guide for simplicity and inclusivity. If Scrum provides value to you, regardless of your specific role, you are considered part of its community.
As Scrum evolves, various context-specific patterns, processes, and insights may emerge that complement the framework described in this guide. However, detailing these is beyond the scope of this Scrum Guide, as they are highly dependent on the specific application of Scrum and can vary greatly. These context-specific tactics are explored in other resources.
Scrum: A Concise Guide to the Framework
Scrum is defined as a lightweight framework designed to enable individuals, teams, and organizations to generate value through adaptive solutions for intricate problems.
In essence, Scrum necessitates a Scrum Master to cultivate an environment where:
- A Product Owner prioritizes and organizes the work for a complex problem into a Product Backlog.
- The Scrum Team transforms a selection of this work into a valuable Increment during a Sprint.
- The Scrum Team and relevant stakeholders review the Increment and make necessary adjustments for subsequent Sprints.
- This cycle is then repeated.
Scrum is intentionally simple. To fully grasp its potential, it should be implemented as described and evaluated based on whether its philosophy, theory, and structure facilitate goal achievement and value creation. The Scrum framework is deliberately designed to be incomplete, specifying only the essential components required to embody Scrum theory. It is meant to be augmented by the collective wisdom of its users. Rather than offering rigid instructions, Scrum’s rules are intended to guide interactions and relationships.
A variety of processes, techniques, and methods can be integrated within this framework. Scrum can complement existing practices or render some obsolete. By highlighting the effectiveness of current management, environmental factors, and work methodologies, Scrum facilitates the identification and implementation of improvements.
Understanding Scrum Theory: A Guide to Empiricism and Lean Thinking
Scrum is rooted in empiricism and lean thinking. Empiricism, in this context, emphasizes that knowledge is derived from experience and decisions are made based on observation. Lean thinking is about minimizing waste and concentrating on what is essential.
Scrum adopts an iterative, incremental approach to enhance predictability and manage risk. It brings together individuals with diverse skills and expertise needed to perform the work, encouraging skill sharing and acquisition as needed.
Scrum incorporates four formal events for inspection and adaptation within a time-boxed event known as the Sprint. These events are effective because they embody the three pillars of empirical Scrum: transparency, inspection, and adaptation.
Transparency: Ensuring Clarity in Scrum Processes
Transparency in Scrum means that the evolving process and the work itself must be visible to both those performing the work and those receiving it. In Scrum, significant decisions are made based on the perceived status of its three formal artifacts. A lack of transparency in these artifacts can lead to poor decisions that reduce value and increase risks.
Transparency is crucial as it enables effective inspection. Inspection without transparency is misleading and unproductive.
Inspection: A Guide to Monitoring Progress in Scrum
Scrum artifacts and progress toward agreed-upon objectives must be frequently and diligently inspected to identify any undesirable deviations or potential problems. To facilitate this, Scrum provides a structured cadence through its five events.
Inspection is vital because it enables adaptation. Inspection without adaptation is considered futile. Scrum events are intentionally structured to prompt necessary changes and improvements.
Adaptation: A Guide to Responding to Change in Scrum
Adaptation in Scrum refers to the necessary adjustments made when any aspect of a process veers outside acceptable limits or if the resulting product is deemed unacceptable. These adjustments must be implemented as promptly as possible to minimize further deviation.
Adaptation is more challenging when team members lack empowerment or self-management capabilities. A Scrum Team is expected to adapt as soon as new insights are gained through inspection.
Scrum Values: Guiding Principles for Team Success
The effective implementation of Scrum hinges on individuals embracing and embodying five core values:
Commitment, Focus, Openness, Respect, and Courage
Scrum Teams are committed to achieving their Sprint Goals and to supporting each other throughout the process. Their primary focus is on the Sprint work, aimed at making optimal progress toward these objectives. Scrum Team members and stakeholders maintain openness regarding their work and any challenges encountered. Respect among Scrum Team members is paramount; they acknowledge each other as competent, independent professionals and are treated as such by their colleagues. Finally, Scrum Team members possess the courage to do what is right and tackle difficult problems head-on.
These values provide direction for the Scrum Team’s work, actions, and interactions. Decisions, actions, and the application of Scrum should reinforce these values, not undermine them. Scrum Team members learn and internalize these values through their involvement in Scrum events and their interaction with Scrum artifacts. When these values are genuinely embraced by the Scrum Team and those they collaborate with, the empirical pillars of transparency, inspection, and adaptation are strengthened, fostering trust and enhancing team dynamics.
The Scrum Team: A Guide to Roles and Responsibilities
The fundamental unit in Scrum is the Scrum Team, a small group of individuals. A Scrum Team comprises a Scrum Master, a Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchical structures. It operates as a cohesive unit of professionals, all focused on a single objective at a time: the Product Goal.
Scrum Teams are cross-functional, meaning they possess all the necessary skills within the team to create value in each Sprint. They are also self-managing, autonomously deciding who does what, when, and how.
Ideally, a Scrum Team is small enough to remain agile yet large enough to accomplish significant work within a Sprint, typically consisting of 10 or fewer people. Smaller teams generally exhibit better communication and higher productivity. If a Scrum Team becomes too large, it should consider reorganizing into multiple, cohesive Scrum Teams, each focused on the same product, sharing the same Product Goal, Product Backlog, and Product Owner.
The Scrum Team is accountable for all product-related activities, from stakeholder collaboration and verification to maintenance, operations, experimentation, research and development, and any other necessary tasks. They are structured and empowered by the organization to manage their work effectively. Working in Sprints at a sustainable pace enhances the Scrum Team’s focus and consistency.
The entire Scrum Team is collectively responsible for delivering a valuable, usable Increment in every Sprint. Scrum defines three specific accountabilities within the Scrum Team: Developers, Product Owner, and Scrum Master.
Developers: A Guide to Building the Increment
Developers are the individuals within the Scrum Team dedicated to creating any aspect of a usable Increment during each Sprint.
The specific skills required of Developers are diverse and depend on the nature of the work domain. However, Developers are always accountable for:
- Developing the Sprint Backlog, which is the plan for the Sprint.
- Ensuring quality by adhering to the Definition of Done.
- Adapting their plan daily to align with the Sprint Goal.
- Holding each other accountable as professionals.
Product Owner: A Guide to Maximizing Product Value
The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work. The methods for achieving this can vary significantly across different organizations, Scrum Teams, and individuals.
The Product Owner is also responsible for effective Product Backlog management, which includes:
- Developing and clearly articulating the Product Goal.
- Creating and clearly communicating Product Backlog items.
- Prioritizing Product Backlog items.
- Ensuring the Product Backlog is transparent, visible, and understood by all.
The Product Owner may perform these tasks personally or delegate them to others, but ultimately, the Product Owner remains accountable.
For Product Owners to be effective, the entire organization must respect their decisions. These decisions are reflected in the content and prioritization of the Product Backlog and are evident in the Increment inspected at the Sprint Review.
The Product Owner is a singular role, not a committee. While the Product Owner represents the needs of numerous stakeholders in the Product Backlog, they are the final decision-maker. Stakeholders wishing to influence the Product Backlog should engage in dialogue and negotiation with the Product Owner.
Scrum Master: A Guide to Scrum Implementation and Team Effectiveness
The Scrum Master is accountable for establishing Scrum as defined in this Scrum Guide. They achieve this by helping everyone involved—both within the Scrum Team and throughout the organization—understand Scrum theory and practice.
The Scrum Master is also accountable for the Scrum Team’s effectiveness. They facilitate this by enabling the Scrum Team to enhance their practices within the Scrum framework.
Scrum Masters are servant-leaders who support the Scrum Team and the broader organization.
The Scrum Master serves the Scrum Team in several key ways, including:
- Coaching team members in self-management and cross-functionality.
- Helping the Scrum Team maintain focus on creating high-value Increments that meet the Definition of Done.
- Facilitating the removal of obstacles hindering the Scrum Team’s progress.
- Ensuring that all Scrum events are conducted as planned, are positive and productive, and adhere to the timebox constraints.
The Scrum Master serves the Product Owner by:
- Helping to identify effective techniques for Product Goal definition and Product Backlog management.
- Assisting the Scrum Team in understanding the necessity for clear and concise Product Backlog items.
- Supporting the establishment of empirical product planning in complex environments.
- Facilitating stakeholder collaboration as needed or requested.
The Scrum Master’s service to the organization includes:
- Leading, training, and coaching the organization in Scrum adoption.
- Planning and advising on Scrum implementations within the organization.
- Helping employees and stakeholders understand and apply an empirical approach to complex work.
- Removing barriers between stakeholders and Scrum Teams.
Scrum Events: A Guide to Inspection and Adaptation Opportunities
The Sprint serves as a container for all other Scrum events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically structured to ensure the necessary transparency. Failure to conduct events as prescribed can result in missed opportunities for inspection and adaptation. Scrum events are used to establish regularity and minimize the need for meetings not defined within Scrum.
Ideally, all events should be held at the same time and location to minimize complexity.
The Sprint: A Guide to Time-boxed Development Cycles
Sprints are the core of Scrum, where ideas are transformed into value.
They are fixed-length events, lasting one month or less, to ensure consistency and predictability. A new Sprint begins immediately after the conclusion of the previous one.
All the work required to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, occurs within Sprints.
During the Sprint:
- No changes are made that could jeopardize the Sprint Goal.
- Quality is maintained and not decreased.
- The Product Backlog is refined as needed.
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring regular inspection and adaptation of progress toward the Product Goal, at least monthly. If a Sprint’s duration is too long, the Sprint Goal may become irrelevant, complexity may increase, and risks may escalate. Shorter Sprints can be used to increase learning cycles and limit the risk of cost and effort within a smaller timeframe. Each Sprint can be viewed as a short-term project.
Various practices, such as burn-down charts, burn-up charts, or cumulative flow diagrams, can be used to forecast progress. While these tools can be helpful, they do not replace the fundamental importance of empiricism. In complex environments, future outcomes are inherently uncertain. Decision-making should primarily be based on what has already occurred.
A Sprint may be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel a Sprint.
Sprint Planning: A Guide to Starting the Sprint Effectively
Sprint Planning is the event that starts the Sprint by outlining the work to be performed. This plan is the result of collaborative effort by the entire Scrum Team.
The Product Owner ensures that participants are prepared to discuss the most critical Product Backlog items and their alignment with the Product Goal. The Scrum Team may also invite external advisors to Sprint Planning for additional insights.
Sprint Planning addresses three key topics:
Topic One: Why is this Sprint Valuable?
The Product Owner proposes how the product could deliver enhanced value and utility during the current Sprint. The entire Scrum Team then collaborates to define a Sprint Goal that articulates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized before Sprint Planning concludes.
Topic Two: What Can Be Done This Sprint?
Through discussions with the Product Owner, the Developers select Product Backlog items to be included in the current Sprint. The Scrum Team may refine these items during this process to improve understanding and confidence in their scope.
Determining the amount of work that can be completed within a Sprint can be challenging. However, the better the Developers understand their past performance, available capacity, and Definition of Done, the more accurate their Sprint forecasts will be.
Topic Three: How Will the Chosen Work Get Done?
For each Product Backlog item selected, the Developers plan the necessary work to create an Increment that meets the Definition of Done. This often involves breaking down Product Backlog items into smaller, more manageable tasks, ideally achievable within a day or less. The methodology for this decomposition is at the discretion of the Developers. No external party dictates how Developers convert Product Backlog items into valuable Increments.
The Sprint Goal, the selected Product Backlog items, and the plan for their delivery collectively form the Sprint Backlog.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the duration of this event is typically reduced.
Daily Scrum: A Guide to Daily Progress and Adaptation
The Daily Scrum’s purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed, adjusting the upcoming planned work.
The Daily Scrum is a brief, 15-minute event for the Developers in the Scrum Team. To minimize disruption, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.
Developers are free to choose any structure and techniques for their Daily Scrum, provided it remains focused on progress toward the Sprint Goal and results in an actionable plan for the day’s work. This promotes focus and enhances self-management.
Daily Scrums improve team communication, help identify impediments, facilitate quick decision-making, and often reduce the need for other meetings.
The Daily Scrum is not the only time Developers can adjust their plan. They frequently meet throughout the day for more detailed discussions to adapt or replan the remaining Sprint work.
Sprint Review: A Guide to Inspecting the Sprint Outcome
The purpose of the Sprint Review is to inspect the Sprint’s outcome and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders, and progress toward the Product Goal is discussed.
During the Sprint Review, the Scrum Team and stakeholders assess what was accomplished in the Sprint and what changes have occurred in their environment. Based on this information, attendees collaborate on next steps. The Product Backlog may be adjusted to reflect new opportunities or changes in direction. The Sprint Review is intended to be a working session, and the Scrum Team should avoid making it solely a presentation.
The Sprint Review is the penultimate event of the Sprint and is time-boxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Sprint Retrospective: A Guide to Continuous Improvement
The Sprint Retrospective is conducted to plan ways to enhance quality and effectiveness.
The Scrum Team inspects the past Sprint in terms of individuals, interactions, processes, tools, and their Definition of Done. The elements reviewed often vary depending on the work domain. Assumptions that led to errors are identified, and their origins are explored. The Scrum Team discusses what went well, what problems were encountered, and how those problems were addressed (or not addressed) during the Sprint.
The Scrum Team identifies the most beneficial changes to improve their effectiveness. The most impactful improvements are addressed as soon as possible and can even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective is the final event of the Sprint and is time-boxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the duration is typically shorter.
Scrum Artifacts: A Guide to Transparency and Value Measurement
Scrum artifacts represent work or value and are designed to maximize transparency of key information. This ensures that everyone inspecting them has a common basis for adaptation.
Each artifact includes a commitment to ensure it provides information that enhances transparency and focus, against which progress can be measured:
- For the Product Backlog, the commitment is the Product Goal.
- For the Sprint Backlog, the commitment is the Sprint Goal.
- For the Increment, the commitment is the Definition of Done.
These commitments reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
Product Backlog: A Guide to Managing Product Work
The Product Backlog is an evolving, ordered list of everything needed to improve the product. It serves as the single source of work undertaken by the Scrum Team.
Product Backlog items that can be completed by the Scrum Team within one Sprint are considered ready for selection during Sprint Planning. This level of readiness is typically achieved through refinement activities. Product Backlog refinement involves breaking down and further defining Product Backlog items into smaller, more precise items. This ongoing process adds details such as descriptions, order, and size. The attributes often vary based on the domain of work.
The Developers who will perform the work are responsible for estimating the size of Product Backlog items. The Product Owner may influence this process by helping Developers understand and consider trade-offs.
Commitment: Product Goal
The Product Goal describes the desired future state of the product and serves as a target for the Scrum Team’s planning. The Product Goal is located within the Product Backlog. The rest of the Product Backlog evolves to define “what” will fulfill the Product Goal.
A product is a means to deliver value. It has clear boundaries, known stakeholders, and well-defined users or customers. A product can be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They should achieve (or decide to abandon) one Product Goal before starting another.
Sprint Backlog: A Guide to Planning Sprint Work
The Sprint Backlog comprises the Sprint Goal (the why), the set of Product Backlog items selected for the Sprint (the what), and an actionable plan for delivering the Increment (the how).
The Sprint Backlog is a plan created by and for the Developers. It is a highly visible, real-time representation of the work the Developers plan to accomplish during the Sprint to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as new information emerges. It should contain enough detail to allow the Developers to inspect their progress during the Daily Scrum.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although it is a commitment made by the Developers, it offers flexibility regarding the specific work needed to achieve it. The Sprint Goal provides coherence and focus, encouraging the Scrum Team to work collaboratively rather than on isolated tasks.
The Sprint Goal is created during Sprint Planning and then added to the Sprint Backlog. As Developers work through the Sprint, they continually keep the Sprint Goal in mind. If the work differs from initial expectations, they collaborate with the Product Owner to adjust the scope of the Sprint Backlog within the Sprint, without compromising the Sprint Goal.
Increment: A Guide to Delivering Value
An Increment is a tangible step toward the Product Goal. Each Increment builds upon all previous Increments and is thoroughly verified to ensure that all Increments function together seamlessly. To be valuable, an Increment must be usable.
Multiple Increments may be created within a single Sprint. The sum of all Increments is presented at the Sprint Review, supporting the principles of empiricism. However, an Increment can be delivered to stakeholders before the Sprint concludes. The Sprint Review should not be seen as a gate for releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done
The Definition of Done is a formal description of the criteria an Increment must meet to satisfy the quality measures required for the product.
An Increment is created the moment a Product Backlog item meets the Definition of Done.
The Definition of Done enhances transparency by providing a shared understanding of what constitutes completed work within an Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it is returned to the Product Backlog for future consideration.
If an organizational standard for the Definition of Done exists, all Scrum Teams must adhere to it as a minimum. If no organizational standard exists, the Scrum Team must develop a Definition of Done that is appropriate for their product.
Developers are obligated to conform to the Definition of Done. If multiple Scrum Teams are working on the same product, they must collaboratively define and adhere to the same Definition of Done.
Final Words: Embracing the Scrum Guide
Scrum is freely available and detailed in this guide. The Scrum framework, as described herein, is immutable. While it is possible to implement only parts of Scrum, the result would not be Scrum. Scrum is effective only when implemented in its entirety, acting as a robust framework that can incorporate other techniques, methodologies, and practices.
Acknowledgements
Contributors
Among the thousands of individuals who have contributed to the evolution of Scrum, special recognition is due to those who were instrumental at its inception: Jeff Sutherland, working with Jeff McKenna and John Scumniotales, and Ken Schwaber, collaborating with Mike Smith and Chris Martin, and all of them working in unison. Numerous others have contributed over the years, and their collective efforts have been crucial in refining Scrum to its current state.
History of the Scrum Guide
Ken Schwaber and Jeff Sutherland jointly presented Scrum for the first time at the OOPSLA Conference in 1995. This presentation documented the insights Ken and Jeff had gained over the preceding years and introduced the first formal definition of Scrum to the public.
The Scrum Guide documents Scrum as it has been developed, evolved, and maintained for over 30 years by Jeff Sutherland and Ken Schwaber. Additional resources offer patterns, processes, and insights that complement the Scrum framework, potentially enhancing productivity, value, creativity, and satisfaction with outcomes.
A comprehensive history of Scrum is available elsewhere. To honor the pioneering organizations where Scrum was first tested and proven, we acknowledge Individual Inc., Newspage, Fidelity Investments, and IDX (now GE Medical).
© 2020 Ken Schwaber and Jeff Sutherland. This publication is licensed under the Creative Commons Attribution Share-Alike license, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and summarized at https://creativecommons.org/licenses/by-sa/4.0/. By using this Scrum Guide, you acknowledge and agree to comply with the terms of the Creative Commons Attribution Share-Alike license.
