This Markdown version of the Scrum Guide mirrors the November 2020 release, accessible as a PDF.
Understanding the Purpose of the Scrum Guide
Scrum’s journey began in the early 1990s, and to clarify its essence for a global audience, we penned the inaugural Scrum Guide in 2010. Since then, we’ve iteratively refined it through focused updates, always in unison.
The Scrum Guide serves as the definitive source for understanding Scrum. Each component within the framework is deliberately designed, contributing uniquely to the overall value and outcomes Scrum delivers. Altering Scrum’s fundamental structure, omitting elements, or disregarding its rules obscures challenges, diminishes benefits, and can potentially render Scrum ineffective.
We observe Scrum’s expanding applications in increasingly intricate environments. It’s inspiring to witness its adoption across diverse fields tackling complex tasks, extending beyond its software development origins. As Scrum’s reach broadens, professionals from various disciplines—developers, researchers, analysts, scientists—become practitioners. In Scrum, we use “developers” inclusively, not exclusively. If Scrum adds value to your work, you are part of the Scrum community.
As Scrum evolves, context-specific patterns, processes, and insights that align with the Scrum framework, as detailed here, may emerge, be applied, and be innovated. Describing these is beyond the scope of this Scrum Guide because they are highly dependent on context and vary significantly across different Scrum implementations. These tactical adaptations within the Scrum framework are diverse and documented elsewhere.
Defining Scrum: A Lightweight Framework for Adaptive Solutions
Scrum is a streamlined framework designed to empower individuals, teams, and organizations to generate value through adaptive solutions for intricate problems.
At its core, Scrum relies on a Scrum Master to cultivate an environment where:
- A Product Owner prioritizes the work for a complex problem within a Product Backlog.
- The Scrum Team transforms a selection of this work into a valuable Increment during a Sprint.
- The Scrum Team and stakeholders review the Increment and make adjustments for the subsequent Sprint.
- This cycle repeats.
Scrum is fundamentally simple. Experiment with it directly to assess if its philosophy, theory, and structure facilitate goal achievement and value creation. The Scrum framework is intentionally minimalist, outlining only the essential components for implementing Scrum theory. It’s built upon the collective wisdom of its users. Rather than imposing rigid instructions, Scrum’s rules guide interactions and relationships.
A variety of processes, techniques, and methodologies can be integrated within this framework. Scrum can complement existing practices or render them unnecessary. It illuminates the effectiveness of current management approaches, environments, and work methodologies, enabling targeted improvements.
Scrum Theory: Empiricism and Lean Thinking at its Foundation
Scrum is grounded in empiricism and lean thinking. Empiricism emphasizes that knowledge stems from experience and data-driven decision-making. Lean thinking focuses on minimizing waste and prioritizing essentials.
Scrum adopts an iterative and incremental approach to enhance predictability and manage risk. It brings together groups with diverse skills and expertise, encouraging skill sharing and acquisition as needed.
Scrum integrates four formal events for inspection and adaptation within a time-boxed Sprint. These events are effective because they embody the empirical Scrum pillars: transparency, inspection, and adaptation.
Transparency: Ensuring Visibility
The evolving process and the work itself must be transparent to both those performing and those receiving the work. In Scrum, critical decisions are informed by the perceived state of its three formal artifacts. Lack of transparency in these artifacts can lead to decisions that erode value and amplify risk.
Transparency is a prerequisite for effective inspection. Inspection without transparency is misleading and unproductive.
Inspection: Frequent Progress Checks
Scrum artifacts and progress toward agreed objectives must be inspected regularly and diligently to identify potential deviations or issues. Scrum’s five events provide a structured cadence for inspection.
Inspection is essential for adaptation. Inspection without adaptation is considered futile. Scrum events are specifically designed to drive necessary changes.
Adaptation: Responding to Change
If any process aspects stray from acceptable boundaries or if the product is deemed unacceptable, the process or materials must be adjusted promptly to minimize further deviation.
Adaptation becomes more challenging when individuals 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 Success
Successful Scrum implementation hinges on individuals embracing five core values:
Commitment, Focus, Openness, Respect, and Courage
The Scrum Team is committed to achieving its objectives and supporting each other. Their primary focus is on the Sprint’s work, striving for optimal progress towards these goals. The Scrum Team and stakeholders maintain openness regarding the work and challenges encountered. Scrum Team members respect each other as competent, independent individuals and are treated with respect by their collaborators. Team members demonstrate courage to pursue the right actions and tackle difficult problems.
These values provide direction for the Scrum Team’s work, actions, and behavior. Decisions, actions, and Scrum application should reinforce these values, not weaken them. Scrum Team members learn and internalize these values through their engagement with Scrum events and artifacts. When these values are embodied by the Scrum Team and their collaborators, the empirical Scrum pillars of transparency, inspection, and adaptation become active, fostering trust.
The Scrum Team: A Unit of Professionals
The fundamental unit in Scrum is a small, cohesive group: the Scrum Team. It comprises a Scrum Master, a Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It’s a unified group of professionals dedicated to a single objective at a time—the Product Goal.
Scrum Teams are cross-functional, possessing all the necessary skills to create value each Sprint. They are also self-managing, autonomously deciding who does what, when, and how.
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 individuals. Smaller teams generally exhibit better communication and higher productivity. If a Scrum Team becomes too large, 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—essentially, anything required for the product. Organizations structure and empower them to manage their own work. Working in Sprints at a sustainable pace enhances the Scrum Team’s focus and consistency.
The entire Scrum Team is responsible for delivering a valuable, usable Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: Developers, Product Owner, and Scrum Master.
Developers: Building the Increment
Developers are the Scrum Team members dedicated to creating any usable Increment component each Sprint.
The specific skills required of Developers are diverse and depend on the work domain. However, Developers are consistently accountable for:
- Creating the Sprint plan, the Sprint Backlog.
- Ensuring quality by adhering to the Definition of Done.
- Adapting their plan daily to achieve the Sprint Goal.
- Holding each other accountable as professionals.
Product Owner: 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 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 describing Product Backlog items.
- Ordering Product Backlog items.
- Ensuring the Product Backlog is transparent, visible, and understood.
The Product Owner may perform these tasks personally or delegate them, but remains ultimately accountable.
For Product Owners to succeed, the entire organization must respect their decisions, which are reflected in the Product Backlog’s content and ordering and in the inspectable Increment at the Sprint Review.
The Product Owner is a single individual, not a committee, though they may represent the needs of numerous stakeholders within the Product Backlog. Stakeholders seeking changes to the Product Backlog should engage in dialogue with the Product Owner to influence it.
Scrum Master: Championing Scrum Effectiveness
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They achieve this by helping everyone understand Scrum theory and practice, both within the Scrum Team and throughout the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness, enabling the team to improve its 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 by:
- Coaching team members in self-management and cross-functionality.
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
- Removing impediments hindering the Scrum Team’s progress.
- Ensuring all Scrum events are conducted and are positive, productive, and within timeboxes.
The Scrum Master serves the Product Owner by:
- Assisting in finding techniques for effective Product Goal definition and Product Backlog management.
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.
- Facilitating empirical product planning in complex environments.
- Facilitating stakeholder collaboration as needed or requested.
The Scrum Master serves the organization by:
- Leading, training, and coaching the organization in Scrum adoption.
- Planning and advising on Scrum implementations within the organization.
- Helping employees and stakeholders understand and implement an empirical approach for complex work.
- Removing barriers between stakeholders and Scrum Teams.
Scrum Events: Opportunities for Inspection and Adaptation
The Sprint is the overarching container for all other Scrum events. Each event is a formal opportunity to inspect and adapt Scrum artifacts, specifically designed to ensure transparency. Failure to conduct events as prescribed leads to missed opportunities for inspection and adaptation. Scrum events establish regularity and minimize the need for meetings outside of Scrum.
Ideally, all events are held at consistent times and locations to minimize complexity.
The Sprint: The Heartbeat of Scrum
Sprints are the core of Scrum, where ideas are transformed into value.
They are time-boxed to one month or less to maintain consistency. A new Sprint begins immediately after the previous one concludes.
All work necessary 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 would jeopardize the Sprint Goal.
- Quality is not compromised.
- The Product Backlog is refined as needed.
- Scope may be clarified and renegotiated with the Product Owner as learning progresses.
Sprints enhance predictability by ensuring regular inspection and adaptation of progress towards the Product Goal, at least monthly. Overly long Sprints can lead to Sprint Goals becoming irrelevant, increased complexity, and heightened risk. Shorter Sprints can provide more frequent learning cycles and limit the risk of cost and effort within a smaller timeframe. Each Sprint can be considered a short-term project.
Various practices like burn-down charts, burn-up charts, or cumulative flow diagrams can be useful for forecasting progress, but they do not replace the fundamental principle of empiricism. In complex environments, future outcomes are uncertain. Only past events can reliably inform forward-looking decisions.
A Sprint can be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel a Sprint.
Sprint Planning: Starting the Sprint with a Plan
Sprint Planning initiates the Sprint by defining the work to be performed. The resulting Sprint Plan is created collaboratively by the entire Scrum Team.
The Product Owner ensures attendees are prepared to discuss the most critical Product Backlog items and their alignment with the Product Goal. The Scrum Team may 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 enhance its value and utility during the Sprint. The entire Scrum Team then collaborates to define a Sprint Goal, articulating the Sprint’s value to stakeholders. The Sprint Goal must be finalized before Sprint Planning concludes.
Topic Two: What Can Be Done this Sprint?
Through discussion with the Product Owner, the Developers select Product Backlog items to include in the Sprint. The Scrum Team may refine these items during this process, improving understanding and confidence.
Determining the amount of work achievable within a Sprint can be challenging. However, the more Developers understand their past performance, upcoming capacity, and Definition of Done, the more accurate their Sprint forecasts will be.
Topic Three: How Will the Chosen Work Get Done?
For each selected Product Backlog item, 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 tasks, ideally one day or less in duration. The method of decomposition is solely at the Developers’ discretion. No one else 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 event duration is typically reduced.
Daily Scrum: 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 upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers, held at the same time and location every working day of the Sprint to minimize complexity. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.
Developers can choose any structure or techniques for their Daily Scrum, as long as it focuses on progress toward the Sprint Goal and generates an actionable plan for the next day’s work. This fosters focus and enhances self-management.
Daily Scrums improve communication, identify impediments, facilitate rapid 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 about adapting or re-planning the remaining Sprint work.
Sprint Review: Inspecting the Increment and Adapting the Product Backlog
The Sprint Review’s purpose is to inspect the Sprint outcome and determine future adaptations. The Scrum Team presents their work results to key stakeholders, and progress towards the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and any changes in their environment. Based on this information, attendees collaborate on next steps. The Product Backlog may be adjusted to reflect new opportunities. The Sprint Review is a working session, and should not be limited to a presentation.
The Sprint Review is the second to last event of the Sprint and is time-boxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event duration is usually shorter.
Sprint Retrospective: Improving Team Effectiveness
The Sprint Retrospective’s purpose is to plan ways to enhance quality and effectiveness.
The Scrum Team examines the past Sprint regarding individuals, interactions, processes, tools, and their Definition of Done. The elements inspected often vary based on the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well, problems encountered, and how those problems were (or were not) resolved.
The Scrum Team identifies the most beneficial changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible, potentially even added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is time-boxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event duration is usually shorter.
Scrum Artifacts: Representing Work and Value
Scrum artifacts represent work or value, designed to maximize transparency of key information, ensuring everyone has a shared understanding for adaptation.
Each artifact includes a commitment to provide 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 stakeholders.
Product Backlog: The Ordered List of Product Improvements
The Product Backlog is a dynamic, ordered list of everything needed to improve the product. It is the single source of work for the Scrum Team.
Product Backlog items that can be completed by the Scrum Team within one Sprint are considered ready for selection in Sprint Planning. They typically achieve this level of clarity through refinement activities. Product Backlog refinement involves breaking down and further defining Product Backlog items into smaller, more precise items, adding details like descriptions, order, and size. Attributes often vary depending on the work domain.
The Developers who will perform the work are responsible for sizing Product Backlog items. The Product Owner can influence sizing by helping Developers understand and consider trade-offs.
Commitment: Product Goal – The Long-Term Objective
The Product Goal describes a desired future state of the product, serving as a target for Scrum Team planning. The Product Goal resides within the Product Backlog. The rest of the Product Backlog evolves to define “what” will achieve the Product Goal.
A product is a vehicle for delivering value. It has clear boundaries, known stakeholders, and 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 must achieve (or decide to abandon) one Product Goal before pursuing the next.
Sprint Backlog: The Plan for the Sprint
The Sprint Backlog comprises the Sprint Goal (why), the selected Product Backlog items (what), and an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan created by and for the Developers. It is a highly visible, real-time representation of the work 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 be detailed enough to enable progress inspection during the Daily Scrum.
Commitment: Sprint Goal – The Sprint Objective
The Sprint Goal is the single objective for the Sprint. While it is a commitment by the Developers, it allows flexibility in the specific work needed to achieve it. The Sprint Goal promotes coherence and focus, encouraging the Scrum Team to collaborate rather than work on isolated tasks.
The Sprint Goal is created during Sprint Planning and added to the Sprint Backlog. As Developers work through the Sprint, they keep the Sprint Goal in mind. If the work differs from initial expectations, they collaborate with the Product Owner to adjust the Sprint Backlog scope without altering the Sprint Goal.
Increment: A Stepping Stone to the Product Goal
An Increment is a tangible step towards the Product Goal. Each Increment builds upon previous Increments and is thoroughly verified to ensure all Increments work cohesively. To provide value, an Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of Increments is presented at the Sprint Review, supporting 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 – Quality Standard
The Definition of Done is a formal description of the Increment’s state when it meets the required quality standards for the product.
An Increment is created the moment a Product Backlog item meets the Definition of Done.
The Definition of Done fosters transparency by providing a shared understanding of what constitutes completed work within the 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 Definition of Done exists, all Scrum Teams must adhere to it as a minimum. If no organizational standard exists, the Scrum Team must create a Definition of Done appropriate for their product.
Developers are required to conform to the Definition of Done. If multiple Scrum Teams are collaborating on a product, they must collectively define and adhere to the same Definition of Done.
End Note: Scrum in its Entirety
Scrum is freely available and detailed in this Guide. The Scrum framework, as outlined here, is immutable. While partial Scrum implementations are possible, they are not Scrum. Scrum exists only as a complete framework and functions effectively as a container for other techniques, methodologies, and practices.
Acknowledgements
People
Among the countless individuals who have contributed to Scrum, we must acknowledge those who were pivotal at the outset: Jeff Sutherland, collaborating with Jeff McKenna and John Scumniotales, and Ken Schwaber, working with Mike Smith and Chris Martin, and their collective efforts. Many others have contributed over the years, and their help has been essential to Scrum’s refinement.
Scrum Guide History
Ken Schwaber and Jeff Sutherland first jointly presented Scrum at the OOPSLA Conference in 1995. This presentation documented the learning Ken and Jeff had accumulated over the preceding years and publicly introduced the first formal definition of Scrum.
The Scrum Guide documents Scrum as developed, evolved, and sustained for over 30 years by Jeff Sutherland and Ken Schwaber. Other sources provide complementary patterns, processes, and insights that enhance the Scrum framework, potentially increasing productivity, value, creativity, and satisfaction with results.
The complete history of Scrum is documented elsewhere. To honor the initial settings where it was tested and proven, we recognize 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-ShareAlike 4.0 International 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 the terms of this license.
