The 2020 Scrum Guide™ serves as the definitive source for understanding Scrum, a framework that has revolutionized the way teams and organizations approach complex problem-solving. Originally developed in the early 1990s, Scrum has evolved and adapted over the years, with the Scrum Guide acting as a living document reflecting its current state. This guide aims to define and explore the essence of the Scrum framework as outlined in the November 2020 version, providing a comprehensive overview for both newcomers and experienced practitioners seeking a deeper understanding.
Purpose and Evolution of the Scrum Guide
The Scrum Guide was first formalized in 2010 by its creators to articulate the core principles and framework of Scrum to a global audience. Since its inception, the guide has undergone iterative updates, each designed to clarify and refine the definition of Scrum based on its growing application across diverse fields. These updates are not about radical changes, but rather functional enhancements intended to improve understanding and application without altering the fundamental nature of Scrum.
The essence of the Scrum Guide lies in its role as the single authoritative source defining Scrum. Each element within the Scrum framework is intentionally designed to serve a specific purpose, contributing to the overall value and effectiveness of Scrum. Altering these core components—whether by omitting elements, changing fundamental concepts, or disregarding Scrum rules—can obscure underlying issues, limit the benefits, and potentially render the framework ineffective. Therefore, adhering to the Scrum Guide is crucial for realizing the intended advantages of Scrum.
Scrum’s adoption has expanded significantly beyond its origins in software product development, now encompassing a wide array of complex work domains. From developers and researchers to analysts and scientists, professionals across various sectors are leveraging Scrum. The Scrum Guide uses the term “developers” in a broad sense, not to be exclusive, but to simplify the language and represent those who are actively involved in creating the product Increment. If your work benefits from Scrum principles, you are considered part of this inclusive definition.
As Scrum continues to be applied in diverse contexts, various patterns, processes, and insights that align with the Scrum framework emerge. However, the Scrum Guide deliberately avoids prescribing these context-specific tactics. Such variations are highly dependent on the specific application of Scrum and are detailed in other resources. The purpose of the Scrum Guide remains focused on defining the core framework, allowing for flexibility in implementation.
Scrum Definition: A Lightweight Framework
Scrum is defined as a lightweight framework designed to help individuals, teams, and organizations generate value through adaptive solutions for complex problems. It is characterized by its simplicity and iterative nature, enabling teams to respond effectively to evolving requirements and challenges.
At its core, Scrum operates through a cyclical process facilitated by a Scrum Master. This process can be summarized in four key steps:
- Product Backlog Creation: The Product Owner takes charge of ordering the work necessary to address a complex problem, organizing it into a Product Backlog. This backlog serves as a dynamic list of features, requirements, and improvements needed for the product.
- Sprint Execution: During a time-boxed period known as a Sprint, the Scrum Team selects a portion of work from the Product Backlog and transforms it into a valuable Increment. This Increment represents tangible progress towards the product goal.
- Inspection and Adaptation: The Scrum Team, along with stakeholders, collaboratively inspects the Increment produced during the Sprint. Based on this inspection, they adapt the Product Backlog and the approach for the subsequent Sprint, ensuring continuous improvement and alignment with evolving needs.
- Iteration: This cycle is repeated, with each Sprint building upon the learnings and outcomes of the previous one, fostering continuous value delivery and adaptation.
Scrum’s power lies in its simplicity. It encourages users to adopt the framework as it is initially defined and then assess whether its philosophy, theory, and structure effectively contribute to achieving goals and creating value. The Scrum framework is intentionally incomplete, defining only the essential components necessary to implement Scrum theory. It is designed to be augmented by the collective intelligence and experience of those who use it. Rather than providing rigid, detailed instructions, Scrum establishes rules that guide interactions and relationships within the team and with stakeholders.
Within this framework, teams can integrate various processes, techniques, and methods that suit their specific context. Scrum is designed to complement existing practices or, in some cases, render them unnecessary by providing a more effective alternative. Crucially, Scrum highlights the effectiveness of current management approaches, work environments, and techniques, making areas for improvement visible and actionable.
Scrum Theory: Empiricism and Lean Thinking
Scrum theory is fundamentally based on empiricism and lean thinking. Empiricism, at its heart, is the belief that knowledge is derived from experience and that decisions should be made based on observation. In Scrum, this translates to learning through doing and continuously inspecting and adapting based on what is experienced during the work. Lean thinking emphasizes minimizing waste and focusing on what is essential to deliver value efficiently. By reducing unnecessary processes and focusing on core value-added activities, Scrum teams can optimize their workflow.
Scrum employs an iterative and incremental approach to enhance predictability and manage risk effectively. The iterative nature of Sprints allows for frequent inspection and adaptation, ensuring that the product evolves in response to feedback and changing conditions. The incremental approach ensures that value is delivered in small, usable increments, allowing for early and continuous value delivery. Scrum brings together individuals who collectively possess the necessary skills and expertise to complete the work. It also promotes skill sharing and acquisition within the team, fostering a collaborative and versatile environment.
The Scrum framework incorporates four formal events for inspection and adaptation, all contained within the overarching Sprint. These events are crucial because they operationalize the empirical pillars of Scrum: transparency, inspection, and adaptation.
Transparency: Ensuring Visibility
Transparency in Scrum means that the emergent process and the work itself must be visible to both those performing the work and those receiving it. This visibility is essential for informed decision-making. In Scrum, critical decisions are based on the perceived state of the three formal Scrum artifacts: the Product Backlog, the Sprint Backlog, and the Increment. If these artifacts lack transparency, decisions made based on them can be flawed, leading to diminished value and increased risk. Transparency is therefore a foundational principle that underpins effective Scrum implementation. It ensures that everyone involved has a shared understanding of the work in progress, the goals, and the challenges.
Transparency is a prerequisite for effective inspection. Without transparency, any inspection efforts will be misleading and wasteful, as they would be based on incomplete or inaccurate information.
Inspection: Frequent Assessment
Inspection in Scrum involves frequently and diligently examining the Scrum artifacts and the progress towards agreed-upon goals. This is done to identify any potentially undesirable deviations, issues, or problems as early as possible. To facilitate regular inspection, Scrum provides a structured cadence through its five events: the Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events serve as formal opportunities to inspect and adapt various aspects of the Scrum process and product. Regular inspection helps ensure that the Scrum Team stays on track, identifies impediments, and makes necessary adjustments to maximize value delivery.
Inspection is essential for enabling adaptation. Inspection without adaptation is considered pointless because the value of identifying issues lies in taking corrective action. Scrum events are specifically designed to prompt change and improvement based on the insights gained from inspection.
Adaptation: Responding to Change
Adaptation is the Scrum pillar that addresses how to respond once inspection reveals deviations or unacceptable outcomes. If any aspect of the process veers outside acceptable limits, or if the resulting product is deemed unacceptable, the process being applied or the materials being produced must be adjusted. Crucially, this adjustment needs to be made as swiftly as possible to minimize further deviation and negative impact. The ability to adapt quickly is a key strength of Scrum, allowing teams to remain flexible and responsive in complex and changing environments.
Adaptation is significantly more challenging when team members are not empowered or lack self-management capabilities. A core principle of Scrum is that the Scrum Team is expected to adapt the moment it learns anything new through inspection. This continuous learning and adaptation cycle is what enables Scrum teams to thrive in complex situations.
Scrum Values: Guiding Principles for Success
Successful implementation of Scrum hinges on individuals embracing and embodying five core values: Commitment, Focus, Openness, Respect, and Courage. These values provide a moral compass for the Scrum Team, guiding their decisions, actions, and interactions.
Commitment, Focus, Openness, Respect, and Courage
- Commitment: The Scrum Team is committed to achieving its Sprint Goals and Product Goals. This commitment extends to supporting each other, fostering a sense of shared responsibility and dedication to success.
- Focus: The primary focus of the Scrum Team is on the work of the Sprint. This intense focus ensures that the team makes the best possible progress towards the Sprint Goal, minimizing distractions and maximizing efficiency.
- Openness: The Scrum Team and its stakeholders maintain openness about all aspects of the work, including progress, challenges, and impediments. This transparency promotes trust and facilitates effective communication and problem-solving.
- Respect: Scrum Team members respect each other as capable, independent professionals. This respect is mutual, extending to stakeholders and all individuals involved in the Scrum process. It fosters a collaborative and supportive environment where diverse perspectives are valued.
- Courage: Scrum Team members possess the courage to do the right thing, even when it is difficult. This includes tackling tough problems, challenging assumptions, and being transparent about progress and impediments. Courage enables teams to address challenges head-on and make necessary changes.
These values provide direction to the Scrum Team in their work, actions, and behavior. Every decision made, every step taken, and every application of Scrum should reinforce these values, not diminish or undermine them. As Scrum Team members engage with Scrum events and artifacts, they learn and internalize these values. When these values are genuinely embodied by the Scrum Team and those they collaborate with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life, building a foundation of trust and enabling high performance.
Scrum Team: Roles and Accountabilities
The fundamental unit in Scrum is the Scrum Team, a small, cross-functional group of people. A Scrum Team is composed of one Scrum Master, one Product Owner, and Developers. Critically, within a Scrum Team, there are no sub-teams or hierarchies. It operates as a cohesive unit of professionals, all focused on a single objective at a time: the Product Goal. This flat structure promotes collaboration, shared accountability, and efficient communication.
Scrum Teams are designed to be cross-functional, meaning that the members collectively possess all the skills necessary to create value in each Sprint. This eliminates dependencies on external teams or individuals, enabling the Scrum Team to work autonomously and efficiently. They are also self-managing, meaning they have the autonomy to decide internally who does what, when, and how. This self-organization empowers the team to optimize their work processes and take ownership of their outcomes.
The ideal Scrum Team size is small enough to remain nimble and adaptable, yet large enough to accomplish significant work within a Sprint. Typically, this means 10 or fewer people. Smaller teams generally exhibit better communication and higher productivity. If a Scrum Team grows too large, it is recommended to reorganize into multiple cohesive Scrum Teams, each focused on the same product. In such cases, these teams should share the same Product Goal, Product Backlog, and Product Owner to maintain alignment and coherence.
The Scrum Team is responsible for all product-related activities, spanning from stakeholder collaboration and verification to maintenance, operation, experimentation, research, and development—essentially, anything required to deliver a valuable product. The organization empowers and structures these teams to manage their own work. Working in Sprints at a sustainable pace enhances the Scrum Team’s focus and consistency, allowing them to deliver value predictably.
The entire Scrum Team is accountable for creating a valuable, usable Increment in every Sprint. Within this team accountability, Scrum defines three specific accountabilities: Developers, Product Owner, and Scrum Master.
Developers: Building the Increment
Developers are the individuals on the Scrum Team who are committed to creating any usable Increment during each Sprint. The term “Developers” encompasses everyone on the Scrum Team who is involved in the actual work of producing the Increment.
The specific skills required of Developers are often diverse and depend on the domain of work. However, Developers are always accountable for:
- Creating the Sprint Backlog: Developers are responsible for creating a plan for the Sprint, which is embodied in the Sprint Backlog. This includes determining how they will achieve the Sprint Goal and deliver the selected Product Backlog items.
- Ensuring Quality (Definition of Done): Developers are accountable for instilling quality by adhering to the Definition of Done. This ensures that the Increment meets agreed-upon quality standards and is truly usable.
- Daily Plan Adaptation: Developers adapt their plan each day during the Daily Scrum to ensure progress towards the Sprint Goal. This daily adaptation is crucial for responding to emerging issues and maintaining focus.
- Professional Accountability: Developers hold each other accountable as professionals. This mutual accountability fosters a high level of responsibility and commitment to quality and teamwork within the Development Team.
Product Owner: Maximizing Product Value
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. This role is central to product success, requiring a deep understanding of the market, users, and business goals. The specific methods and strategies employed by Product Owners can vary widely across organizations, Scrum Teams, and individual styles.
The Product Owner is also accountable for effective Product Backlog management. This encompasses several key activities:
- Developing and Communicating the Product Goal: The Product Owner is responsible for defining and explicitly communicating the Product Goal. This long-term goal provides direction and purpose for the Scrum Team’s work.
- Creating and Communicating Product Backlog Items: The Product Owner creates and clearly communicates Product Backlog items. These items represent the features, functionalities, and improvements needed for the product.
- Ordering Product Backlog Items: The Product Owner orders Product Backlog items to best achieve the Product Goal and maximize value. This prioritization ensures that the most valuable work is addressed first.
- Ensuring Product Backlog Transparency: The Product Owner ensures that the Product Backlog is transparent, visible, and understood by all stakeholders. This transparency is essential for alignment and informed decision-making.
While the Product Owner may delegate some of these Product Backlog management tasks to others, they ultimately remain accountable for their effective execution.
For Product Owners to be successful, the entire organization must respect their decisions. These decisions are reflected in the content and ordering of the Product Backlog and are validated through the inspectable Increment presented at the Sprint Review. Organizational support and respect for the Product Owner’s authority are crucial for effective product management in a Scrum environment.
The Product Owner is a single individual, not a committee. While the Product Owner represents the needs of many stakeholders in the Product Backlog, they act as the central decision-maker for product-related matters. Stakeholders who wish to influence the Product Backlog do so by engaging with and attempting to persuade the Product Owner.
Scrum Master: Servant-Leader and Process Facilitator
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. This role is critical for ensuring that Scrum is understood and effectively applied within both the Scrum Team and the broader organization. The Scrum Master acts as a process authority and coach, guiding the team and organization in their Scrum journey.
The Scrum Master is also accountable for the Scrum Team’s effectiveness. This is achieved by enabling the Scrum Team to improve its practices within the Scrum framework. The Scrum Master is not responsible for the team’s output directly, but rather for creating an environment where the team can be as productive and efficient as possible.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization. Their leadership style is one of servant leadership, focused on supporting and empowering others rather than directing or controlling them.
The Scrum Master serves the Scrum Team in several key ways:
- Coaching: The Scrum Master coaches team members in self-management and cross-functionality. This helps the team become more autonomous and capable.
- Focus on Value: The Scrum Master helps the Scrum Team focus on creating high-value Increments that meet the Definition of Done. This ensures that the team is always working towards delivering valuable outcomes.
- Impediment Removal: The Scrum Master is responsible for causing the removal of impediments that hinder the Scrum Team’s progress. This may involve resolving organizational issues, process bottlenecks, or external dependencies.
- Event Facilitation: The Scrum Master ensures that all Scrum events take place and are positive, productive, and kept within the timebox. This includes facilitating the events effectively and ensuring they achieve their intended purpose.
The Scrum Master also serves the Product Owner in several ways:
- Product Goal and Backlog Techniques: The Scrum Master helps find techniques for effective Product Goal definition and Product Backlog management. This supports the Product Owner in effectively managing the product vision and backlog.
- Clear Backlog Items: The Scrum Master helps the Scrum Team understand the need for clear and concise Product Backlog items. This improves communication and reduces ambiguity.
- Empirical Product Planning: The Scrum Master helps establish empirical product planning for complex environments. This supports the Product Owner in planning and forecasting in uncertain situations.
- Stakeholder Collaboration: The Scrum Master facilitates stakeholder collaboration as requested or needed. This ensures that the Product Owner can effectively engage with stakeholders and gather necessary input.
Finally, the Scrum Master serves the organization in several ways:
- Scrum Adoption Leadership: The Scrum Master leads, trains, and coaches the organization in its Scrum adoption. This includes promoting Scrum values and principles throughout the organization.
- Scrum Implementation Planning: The Scrum Master plans and advises Scrum implementations within the organization. This ensures that Scrum is adopted effectively and appropriately in different contexts.
- Empirical Approach Advocacy: The Scrum Master helps employees and stakeholders understand and enact an empirical approach for complex work. This promotes a culture of learning and adaptation.
- Barrier Removal: The Scrum Master removes barriers between stakeholders and Scrum Teams. This improves communication and collaboration across the organization.
Scrum Events: Opportunities for Inspection and Adaptation
The Sprint serves as a container for all other Scrum events. Each event in Scrum is a formal opportunity to inspect Scrum artifacts and adapt processes as needed. These events are specifically structured to ensure the necessary transparency for effective Scrum implementation. Failure to conduct these events as prescribed can lead to missed opportunities for inspection and adaptation, hindering the potential benefits of Scrum. Scrum events are designed to create a regular rhythm and minimize the need for additional meetings outside of the defined Scrum framework.
Ideally, all events should be held at the same time and place to reduce complexity and ensure predictability. This consistency helps establish a routine and makes it easier for team members to participate effectively.
The Sprint: The Heartbeat of Scrum
Sprints are the fundamental building blocks of Scrum, representing fixed-length iterations where ideas are transformed into value. They are time-boxed events of one month or less in duration, designed to create consistency and predictability in the development cycle. A new Sprint begins immediately after the conclusion of the previous Sprint, creating a continuous flow of work.
All the necessary Scrum activities to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, occur within Sprints. The Sprint itself acts as a container for these events, providing a structured framework for iterative development.
During a Sprint, several key principles are maintained:
- Sprint Goal Stability: No changes are made that would jeopardize the Sprint Goal. This provides focus and stability for the team during the Sprint.
- Quality Maintenance: Quality levels do not decrease during the Sprint. The commitment to the Definition of Done ensures consistent quality.
- Product Backlog Refinement: The Product Backlog is refined as needed throughout the Sprint. This ongoing refinement ensures that the backlog remains current and well-understood.
- Scope Clarification and Renegotiation: Scope may be clarified and renegotiated with the Product Owner as more is learned during the Sprint. This flexibility allows for adaptation based on new information.
Sprints enhance predictability by ensuring regular inspection and adaptation of progress towards the Product Goal, occurring at least every calendar month. If a Sprint’s duration is too long, the Sprint Goal may become outdated, complexity may increase, and risks may escalate. Shorter Sprints can be employed to generate more frequent learning cycles and limit the risk of cost and effort to a smaller timeframe. Each Sprint can be viewed as a short project with a defined goal and deliverable.
Various practices, such as burn-down charts, burn-up charts, or cumulative flow diagrams, can be used to forecast progress within a Sprint. 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 and been observed.
A Sprint can be cancelled if the Sprint Goal becomes obsolete. However, only the Product Owner has the authority to cancel a Sprint. This decision is typically made in consultation with the Scrum Team and stakeholders.
Sprint Planning: Initiating the Sprint
Sprint Planning is the event that kicks off the Sprint. Its purpose is to lay out the work to be performed during the Sprint. This resulting plan, known as the Sprint Backlog, is created through the collaborative effort of the entire Scrum Team. Effective Sprint Planning is crucial for setting the direction and focus for the Sprint.
The Product Owner is responsible for ensuring that attendees are prepared to discuss the most important Product Backlog items and how they align with the Product Goal. The Scrum Team may also invite other individuals to Sprint Planning to provide specialized advice or insights.
Sprint Planning addresses three key topics:
Topic One: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The entire Scrum Team then collaborates to define a Sprint Goal that clearly communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized before the end of Sprint Planning. This ensures that everyone understands the overarching objective of the Sprint.
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select Product Backlog items to include in the current Sprint. The Scrum Team may refine these items during this selection process, leading to increased understanding and confidence in their ability to deliver them. This collaborative selection ensures that the team commits to work that is both valuable and achievable within the Sprint timeframe.
Determining how much work can be completed within a Sprint can be challenging. However, the more the Developers understand their past performance, their current capacity, and the Definition of Done, the more accurate and confident they will be in their Sprint forecasts. Historical data and a clear understanding of capacity are valuable inputs for this topic.
Topic Three: How will the chosen work get done?
For each Product Backlog item selected for the Sprint, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This often involves breaking down Product Backlog items into smaller, more manageable work items, ideally of one day or less. The methodology for doing this is at the sole discretion of the Developers. No one else dictates to them how to transform Product Backlog items into valuable Increments. This empowers the Developers to self-organize and determine the best approach to achieve the Sprint Goal.
The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them collectively constitute the Sprint Backlog. The Sprint Backlog is a dynamic plan that guides the work throughout the Sprint.
Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event duration is typically shorter, scaled proportionally to the Sprint length.
Daily Scrum: Daily Progress Inspection
The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. This daily synchronization helps the Developers stay aligned and identify any impediments early on.
The Daily Scrum is a brief, 15-minute event specifically for the Developers of the Scrum Team. To minimize complexity and promote routine, 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 items in the Sprint Backlog, they participate as Developers in the Daily Scrum.
Developers have the autonomy to choose whatever structure and techniques they find most effective for their Daily Scrum, as long as it focuses on progress towards the Sprint Goal and results in an actionable plan for the next day of work. This self-organization promotes ownership and efficiency.
Daily Scrums improve communication, identify impediments, promote rapid decision-making, and consequently reduce the need for other status-update meetings. The Daily Scrum is a focused and efficient way to keep the team synchronized.
The Daily Scrum is not the only opportunity for Developers to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the remaining work of the Sprint. The Daily Scrum serves as a starting point for ongoing communication and collaboration.
Sprint Review: Demonstrating and Inspecting the Increment
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations to the Product Backlog. During this event, the Scrum Team presents the results of their work to key stakeholders, and progress towards the Product Goal is discussed. The Sprint Review provides a valuable opportunity to gather feedback and ensure alignment with stakeholder needs.
During the Sprint Review, the Scrum Team and stakeholders jointly review what was accomplished in the Sprint and what changes have occurred in their environment. Based on this information, attendees collaborate on what actions to take next. The Product Backlog may be adjusted to reflect new opportunities or changing priorities. The Sprint Review is intended to be a working session, and the Scrum Team should avoid limiting it to a mere presentation. Active participation and feedback are essential.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is typically shorter, scaled to the Sprint duration.
Sprint Retrospective: Improving Team Effectiveness
The primary purpose of the Sprint Retrospective is to plan ways to enhance quality and effectiveness within the Scrum Team. It focuses on continuous improvement of the team’s processes, tools, and interactions.
The Scrum Team inspects how the last Sprint went in terms of individuals, interactions, processes, tools, and their Definition of Done. The specific elements inspected may vary depending on the domain of work. Assumptions that led the team astray are identified, and their root causes are explored. The Scrum Team discusses what went well during the Sprint, what problems were encountered, and how those problems were (or were not) resolved. This open and honest reflection is essential for learning and growth.
The Scrum Team then identifies the most beneficial changes to improve its effectiveness. The most impactful improvements are prioritized and addressed as soon as possible. These improvements may even be added to the Product Backlog for the next Sprint, ensuring that they are acted upon.
The Sprint Retrospective concludes the Sprint, providing a formal opportunity for reflection and improvement before the next Sprint begins. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event duration is typically shorter.
Scrum Artifacts: Transparency and Opportunity for Adaptation
Scrum artifacts represent work or value within the Scrum framework. Their primary design goal is to maximize transparency of key information. This transparency ensures that everyone inspecting them has a common basis for adaptation and decision-making. Well-defined artifacts are essential for effective Scrum implementation.
Each Scrum 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 both the Scrum Team and their stakeholders. They provide clarity and purpose to each artifact.
Product Backlog: The Plan for What to Build
The Product Backlog is an emergent, ordered list of everything that is known to be needed in the product. It is the single, definitive source of work undertaken by the Scrum Team. The Product Backlog is a dynamic artifact that evolves as the product and its environment change.
Product Backlog items that are realistically achievable by the Scrum Team within one Sprint are considered ready for selection in a Sprint Planning event. These items typically achieve this state of readiness after undergoing refinement activities. Product Backlog refinement is the ongoing process of breaking down and further defining Product Backlog items into smaller, more precise items. This refinement includes adding details such as descriptions, order, and size estimations. The specific attributes refined often depend on the domain of work.
The Developers who will be doing the work are responsible for sizing or estimating the effort for Product Backlog items. The Product Owner may influence the Developers by helping them understand and make informed trade-offs. Collaboration between the Product Owner and Developers during refinement is crucial.
Commitment: Product Goal – The Vision
The Product Goal describes a future state of the product that serves as a target for the Scrum Team to plan against. The Product Goal is contained within the Product Backlog. The rest of the Product Backlog emerges and evolves to define “what” will fulfill this Product Goal. The Product Goal provides long-term vision and direction for the product development effort.
A product is defined as a vehicle to deliver value. It possesses a clear boundary, known stakeholders, and well-defined users or customers. A product can take many forms, including a service, a physical product, or even something more abstract.
The Product Goal represents the long-term objective for the Scrum Team. Teams are expected to fulfill one Product Goal (or decide to abandon it) before embarking on the next. This focus on a single Product Goal at a time helps maintain strategic alignment and focus.
Sprint Backlog: The Plan for How to Achieve the Sprint Goal
The Sprint Backlog is composed of three key elements: the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). It is the tactical plan for the current Sprint.
The Sprint Backlog is a plan created by and for the Developers. It serves as a highly visible, real-time representation of the work that 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 is learned or circumstances change. It should contain sufficient detail to enable the Developers to effectively inspect their progress during the Daily Scrum.
Commitment: Sprint Goal – The Sprint Objective
The Sprint Goal is the single, overarching objective for the Sprint. While the Sprint Goal represents a commitment by the Developers, it also provides flexibility regarding the precise work needed to achieve it. The Sprint Goal fosters coherence and focus, encouraging the Scrum Team to work together as a unified team rather than on isolated tasks. It provides a shared purpose for the Sprint.
The Sprint Goal is created during the Sprint Planning event and is then added to the Sprint Backlog. As the Developers work throughout the Sprint, they continuously keep the Sprint Goal in mind. If the work unfolds differently than anticipated, they collaborate with the Product Owner to adjust the scope of the Sprint Backlog within the Sprint, always ensuring that the Sprint Goal remains unaffected. The Sprint Goal acts as a compass, guiding the team’s decisions and actions.
Increment: The Tangible Result of the Sprint
An Increment is a concrete stepping stone towards the Product Goal. Each Increment is additive to all preceding Increments, and it is thoroughly verified to ensure that all Increments function seamlessly together. To be considered valuable, an Increment must be usable, meaning it provides tangible value to the users or stakeholders. The Increment represents the sum of all Product Backlog items completed during a Sprint.
Multiple Increments may be created within a single Sprint. The cumulative Increment, representing the sum of all Increments created to date, is presented at the Sprint Review, supporting the empirical nature of Scrum by providing inspectable progress. However, an Increment may be delivered to stakeholders before the end of the Sprint if it provides value. The Sprint Review should never be viewed as a gate for releasing value; value delivery can be continuous.
Work cannot be considered part of an Increment unless it fully meets the Definition of Done. The Definition of Done is a critical quality gate in Scrum.
Commitment: Definition of Done – Quality Standard
The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding of what “Done” means for the Increment.
The moment a Product Backlog item satisfies the Definition of Done, an Increment is considered “born.” This marks the completion of work on that item within the Sprint.
The Definition of Done establishes transparency by providing everyone with 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 and further work. The DoD ensures that only high-quality, usable Increments are delivered.
If a Definition of Done is already established as part of the organization’s standards, all Scrum Teams within that organization must adhere to it as a minimum baseline. If no organizational standard exists, the Scrum Team must create a Definition of Done that is appropriate for their specific product. The Scrum Team is collectively responsible for defining and adhering to the DoD.
The Developers are obligated to conform to the Definition of Done. If multiple Scrum Teams are working together on the same product, they must mutually define and consistently comply with the same Definition of Done to ensure integration and consistent quality across all teams.
End Note: Scrum’s Immutable Framework
Scrum is provided freely and is fully described in this Scrum Guide. The Scrum framework, as outlined in this guide, is immutable. While it is possible to implement only parts of Scrum, the resulting approach is not Scrum itself. True Scrum exists only in its entirety and functions effectively as a container for integrating other techniques, methodologies, and practices that complement its core framework. It is designed to be a complete yet adaptable framework for complex work.
Acknowledgements
People Who Shaped Scrum
Among the countless individuals who have contributed to the evolution of Scrum, special recognition is due to those who were instrumental in its initial development: Jeff Sutherland, working with Jeff McKenna and John Scumniotales, and Ken Schwaber, collaborating with Mike Smith and Chris Martin. All of these individuals worked together and with many others in the years that followed. Their collective contributions have been essential to refining Scrum into its current form.
Scrum Guide History and Evolution
Ken Schwaber and Jeff Sutherland jointly presented Scrum for the first time at the OOPSLA Conference in 1995. This initial presentation documented the learning they had accumulated over the preceding years and publicly introduced the first formal definition of Scrum.
The Scrum Guide itself documents Scrum as it has been developed, evolved, and sustained over more than 30 years by Jeff Sutherland and Ken Schwaber. Numerous other resources offer patterns, processes, and insights that enhance the Scrum framework, contributing to increased productivity, value delivery, creativity, and satisfaction with outcomes.
A comprehensive history of Scrum is available in other publications. To acknowledge the pioneering organizations where Scrum was first tested and proven, we recognize Individual Inc., Newspage, Fidelity Investments, and IDX (now GE Medical).
© 2020 Ken Schwaber and Jeff Sutherland. This publication is offered 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 be bound by the terms of this Creative Commons Attribution Share-Alike license.
