The Scrum Guide serves as the definitive source for understanding Scrum, a lightweight framework designed to help individuals, teams, and organizations generate value through adaptive solutions for complex problems. Initially developed in the early 1990s, the Scrum Guide was first formalized in 2010 to provide a clear and accessible explanation of Scrum principles and practices to a global audience. It has since been iteratively updated to reflect the evolving understanding and application of Scrum in diverse contexts.
The Purpose and Essence of the Scrum Guide
The Scrum Guide’s primary purpose is to offer a concise and authoritative definition of Scrum. Each component within the Scrum framework is meticulously designed to fulfill a specific function, contributing to the overall effectiveness and value derived from Scrum implementation. Altering Scrum’s fundamental structure, omitting essential elements, or disregarding Scrum’s rules can obscure underlying issues, diminish potential benefits, and potentially render the framework ineffective.
Scrum’s adaptability has led to its widespread adoption across various complex domains, extending beyond its origins in software product development. While the term “developers” is used throughout the Scrum Guide, it is intended in a broad sense to encompass all individuals who contribute to the work, including developers, researchers, analysts, scientists, and other specialists. Anyone who finds value in Scrum is considered part of this inclusive community.
As Scrum continues to be applied in diverse scenarios, various patterns, processes, and insights that align with the Scrum framework have emerged. However, the Scrum Guide intentionally refrains from detailing these context-specific tactics, as they vary significantly depending on the specific application of Scrum. Such practical implementations within the Scrum framework are documented and explored in other resources.
Unpacking the Scrum Definition
At its core, Scrum is defined as a lightweight framework that empowers people, teams, and organizations to generate value through adaptive solutions when tackling complex challenges. It’s a guide that promotes agility and iterative development.
In essence, Scrum operates with a Scrum Master who cultivates an environment characterized by the following iterative cycle:
- A Product Owner strategically organizes the work related to a complex problem into a Product Backlog, essentially creating a prioritized guide for development.
- The Scrum Team, guided by the Product Backlog, transforms a selection of work items into a valuable Increment during a Sprint, which acts as a time-boxed iteration.
- The Scrum Team and relevant stakeholders collaboratively inspect the Increment and make necessary adjustments for the subsequent Sprint, ensuring continuous improvement and adaptation based on feedback and results.
- This cycle is then repeated, fostering a continuous loop of development, inspection, and adaptation.
Scrum is intentionally designed to be simple and straightforward. The best way to understand its effectiveness is to implement it as described and assess whether its philosophy, theory, and structure contribute to achieving objectives and creating value. The Scrum framework is deliberately incomplete, focusing solely on the essential components required to embody Scrum theory. It thrives on the collective intelligence of its users, providing guiding principles rather than rigid instructions, allowing the rules of Scrum to shape relationships and interactions within the team and with stakeholders.
The framework is versatile and can accommodate various processes, techniques, and methods. Scrum can integrate with existing practices or, in some cases, render them unnecessary by providing a more efficient and effective alternative. Crucially, Scrum brings transparency to the effectiveness of current management approaches, work environments, and techniques, highlighting areas for potential improvement.
The Theoretical Foundation of Scrum: Empiricism and Lean Thinking
Scrum’s theoretical underpinnings are rooted in empiricism and lean thinking. Empiricism, a cornerstone of Scrum, emphasizes that knowledge is derived from experience, advocating for decision-making based on observation and evidence. Lean thinking, another crucial element, focuses on minimizing waste and concentrating on essential elements, ensuring efficiency and value maximization.
Scrum adopts an iterative and incremental approach to enhance predictability and manage risk effectively. By breaking down complex projects into smaller, manageable Sprints, Scrum enables frequent inspection and adaptation, allowing for course correction as needed. Scrum thrives on the collective expertise of diverse teams, bringing together individuals with the necessary skills to accomplish the work. It encourages skill sharing and acquisition, fostering a collaborative and adaptable environment.
Within the overarching Sprint, Scrum incorporates four formal events specifically designed for inspection and adaptation. These events are integral to implementing Scrum’s empirical pillars: transparency, inspection, and adaptation, ensuring that progress is visible, reviewed, and adjusted as needed.
Transparency: Ensuring Clarity and Visibility
Transparency is paramount in Scrum. The processes and work in progress must be clearly visible to both those performing the work and those receiving the results. In Scrum, critical decisions are informed by the perceived state of the three formal artifacts: the Product Backlog, the Sprint Backlog, and the Increment. If these artifacts lack transparency, it can lead to misguided decisions that diminish value and increase risks.
Transparency is a prerequisite for effective inspection. Attempting to inspect without transparency is misleading and wasteful, as it relies on incomplete or inaccurate information.
Inspection: Frequent Review for Continuous Improvement
Scrum mandates frequent and diligent inspection of the Scrum artifacts and progress toward agreed-upon goals. This continuous review process is essential for identifying potential deviations or problems early on. To facilitate inspection, Scrum incorporates cadence through its five events: the Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events provide structured opportunities to examine progress and identify areas for adjustment.
Inspection is crucial for enabling adaptation. Inspection without subsequent adaptation is considered unproductive. Scrum events are intentionally designed to trigger necessary changes based on the insights gained through inspection.
Adaptation: Embracing Change and Course Correction
Adaptation is the mechanism for responding to deviations and ensuring continuous improvement. If any aspect of a process veers outside acceptable boundaries or if the resulting product is deemed unsatisfactory, the process or materials must be promptly adjusted. Timely adaptation is essential to minimize further deviation and maintain alignment with goals.
Adaptation is most effective when individuals are empowered and self-managing. Scrum Teams are expected to embrace adaptation proactively, adjusting their approach as soon as new information is learned through inspection. This agility and responsiveness are key to Scrum’s effectiveness in complex environments.
The Guiding Values of Scrum
The successful implementation of Scrum hinges on individuals embracing and embodying five core values: Commitment, Focus, Openness, Respect, and Courage. These values act as a compass, guiding the Scrum Team’s work, actions, and behavior.
Commitment, Focus, Openness, Respect, and Courage
The Scrum Team demonstrates commitment by dedicating themselves to achieving their goals and providing mutual support. Their primary focus is on the Sprint’s work, striving to make optimal progress toward the Sprint Goal. Openness is fostered through transparent communication between the Scrum Team and stakeholders regarding the work and any challenges encountered. Respect is fundamental, with Scrum Team members acknowledging each other’s capabilities and independence, and extending that respect to all collaborators. Courage empowers Scrum Team members to act ethically, tackle difficult problems, and advocate for what is right, even when faced with adversity.
These values provide direction for the Scrum Team in their work, actions, and interactions. Decisions made, steps taken, and the overall application of Scrum should reinforce these values, not undermine them. Scrum Team members learn and deepen their understanding of these values through their engagement with Scrum events and artifacts. When these values are deeply ingrained within the Scrum Team and their collaborators, the empirical pillars of transparency, inspection, and adaptation become vibrant and effective, fostering trust and collaboration.
The Scrum Team: Roles and Responsibilities Defined
The fundamental unit in Scrum is the Scrum Team, a small, cohesive group of individuals. A Scrum Team comprises one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchical structures. It functions as a unified entity of professionals, all focused on a singular objective at any given time: the Product Goal.
Scrum Teams are inherently cross-functional, meaning their members possess all the necessary skills to create value in each Sprint. They are also self-managing, empowered to make internal decisions regarding who performs specific tasks, when those tasks are carried out, and how they are executed. This self-organization fosters autonomy and accountability within the team.
The ideal Scrum Team size is small enough to maintain agility and responsiveness, 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, it is advisable to reorganize into multiple cohesive Scrum Teams, each focused on the same product, sharing the same Product Goal, Product Backlog, and Product Owner.
The Scrum Team collectively assumes responsibility for all product-related activities, encompassing stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and any other tasks that may be required throughout the product lifecycle. They are structured and empowered by the organization to manage their own work effectively. Working in Sprints at a sustainable pace enhances the Scrum Team’s focus and consistency, leading to more predictable outcomes.
The entire Scrum Team is accountable for delivering a valuable and usable Increment in every Sprint. Within this team accountability, Scrum defines three specific accountabilities: Developers, Product Owner, and Scrum Master, each with distinct responsibilities and contributions.
Developers: Building the Increment
Developers are the individuals within the Scrum Team who are dedicated to creating any usable aspect of the Increment during each Sprint. The specific skills required of Developers are diverse and depend on the nature of the work domain. However, Developers are consistently accountable for:
- Developing a comprehensive plan for the Sprint, embodied in the Sprint Backlog, outlining how they will achieve the Sprint Goal.
- Ensuring quality by adhering to a well-defined Definition of Done, setting a clear standard for acceptable work.
- Adapting their plan daily in pursuit of the Sprint Goal, demonstrating flexibility and responsiveness to emerging insights.
- Holding each other accountable as professionals, fostering a culture of shared responsibility and high standards.
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 specific methods employed to achieve this can vary widely across organizations, Scrum Teams, and individual Product Owners. Effectively, the Product Owner guides the direction of the product.
The Product Owner is also responsible for effective Product Backlog management, which includes:
- Developing and clearly articulating the Product Goal, providing a long-term vision for the product.
- Creating and clearly communicating Product Backlog items, ensuring that the work to be done is well-defined and understood.
- Ordering Product Backlog items to optimize value delivery, prioritizing the most important work.
- Ensuring that the Product Backlog is transparent, visible, and understood by all stakeholders, fostering shared awareness and alignment.
The Product Owner may delegate some of these tasks to others, but ultimately remains accountable for Product Backlog management.
For Product Owners to be successful, the entire organization must respect their decisions. These decisions are reflected in the content and prioritization of the Product Backlog and are validated through the inspectable Increment presented at the Sprint Review.
The Product Owner is a single individual, not a committee, ensuring clear decision-making and accountability. The Product Owner represents the needs of numerous stakeholders in the Product Backlog, synthesizing diverse perspectives into a unified product vision. Individuals seeking to influence the Product Backlog can do so by engaging in constructive dialogue and persuasion with the Product Owner.
Scrum Master: Championing Scrum Effectiveness
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. This involves guiding everyone in understanding Scrum theory and practice, both within the Scrum Team and throughout the organization. The Scrum Master acts as a guide for Scrum implementation.
The Scrum Master is also accountable for the Scrum Team’s effectiveness, enabling the team to continuously improve its practices within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the broader organization, fostering a culture of agility and continuous improvement.
The Scrum Master serves the Scrum Team in various ways, including:
- Coaching team members in self-management and cross-functionality, empowering them to take ownership and collaborate effectively.
- Helping the Scrum Team maintain focus on creating high-value Increments that meet the Definition of Done, ensuring quality and value delivery.
- Facilitating the removal of impediments that hinder the Scrum Team’s progress, clearing obstacles to productivity.
- Ensuring that all Scrum events take place as scheduled, are positive and productive, and adhere to the timebox constraints, maximizing the value of each event.
The Scrum Master also serves the Product Owner by:
- Helping identify effective techniques for Product Goal definition and Product Backlog management, enhancing product vision and planning.
- Guiding the Scrum Team in understanding the importance of clear and concise Product Backlog items, improving communication and clarity.
- Facilitating empirical product planning in complex environments, enabling data-driven decision-making.
- Facilitating stakeholder collaboration as needed or requested, fostering effective communication and alignment.
Furthermore, the Scrum Master serves the organization by:
- Leading, training, and coaching the organization in its Scrum adoption, promoting widespread understanding and effective implementation.
- Planning and advising on Scrum implementations across the organization, ensuring consistent and successful adoption.
- Helping employees and stakeholders understand and embrace an empirical approach for complex work, fostering a culture of learning and adaptation.
- Removing barriers between stakeholders and Scrum Teams, improving collaboration and communication across organizational boundaries.
Scrum Events: Structured Opportunities for Inspection and Adaptation
The Sprint serves as a container for all other Scrum events. Each event in Scrum is a formally defined opportunity to inspect and adapt Scrum artifacts, ensuring transparency and facilitating continuous improvement. These events are specifically designed to enable the necessary transparency for effective Scrum implementation. Failure to conduct events as prescribed results in missed opportunities for inspection and adaptation, potentially hindering progress and value delivery. Scrum events are used to establish regularity and minimize the need for ad-hoc meetings outside of the defined Scrum framework.
Ideally, all events are held at consistent times and locations to minimize complexity and streamline coordination.
The Sprint: The Heartbeat of Scrum
Sprints are the fundamental building blocks of Scrum, representing fixed-length iterations (one month or less) where ideas are transformed into value. They are the heartbeat of Scrum, driving consistent progress and providing a regular rhythm for development. A new Sprint commences immediately after the conclusion of the preceding Sprint, creating a continuous cycle of development and delivery.
All essential Scrum activities, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, take place within the Sprint timeframe.
During the Sprint:
- No changes are introduced that would jeopardize the Sprint Goal, maintaining focus and stability.
- Quality standards are upheld, ensuring that the Increment meets the Definition of Done.
- The Product Backlog is refined as needed to ensure its continued relevance and clarity.
- Scope may be clarified and renegotiated with the Product Owner as new insights emerge, allowing for flexibility and adaptation.
Sprints enhance predictability by ensuring regular inspection and adaptation of progress toward the Product Goal at least monthly. Extended Sprint durations can lead to Sprint Goals becoming obsolete, increased complexity, and heightened risks. Shorter Sprints can be employed to accelerate learning cycles and limit the potential impact of risks within a smaller timeframe. Each Sprint can be viewed as a short, focused project with a defined objective.
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 must be grounded in what has already occurred, leveraging empirical data for forward planning.
A Sprint can be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel a Sprint, reflecting their responsibility for product value and direction.
Sprint Planning: Setting the Stage for the Sprint
Sprint Planning marks the initiation of the Sprint, establishing the work to be undertaken during the Sprint. This plan is collaboratively developed by the entire Scrum Team, leveraging their collective expertise.
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 experts 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 articulates how the product could generate increased value and utility in the current Sprint. The entire Scrum Team then collaborates to define a Sprint Goal that clearly communicates the Sprint’s value to stakeholders. The Sprint Goal must be finalized before Sprint Planning concludes, providing a clear and shared objective for the Sprint.
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, enhancing understanding and confidence in their feasibility.
Determining the amount of work that can be realistically completed within a Sprint can be challenging. However, the more insights Developers have into their past performance, available capacity, and the Definition of Done, the more accurate and confident they will be in their Sprint forecasts.
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, 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 of one day or less. The specific approach to task breakdown is at the sole discretion of the Developers, respecting their expertise and autonomy. No external party dictates how Developers transform Product Backlog items into valuable Increments.
The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for their delivery collectively constitute the Sprint Backlog, a comprehensive roadmap for 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 reduced proportionally.
Daily Scrum: Daily Synchronization and Progress Check
The Daily Scrum serves the purpose of inspecting progress toward the Sprint Goal and adapting the Sprint Backlog as needed, adjusting upcoming planned work based on current understanding.
The Daily Scrum is a brief, 15-minute event specifically for the Developers of the Scrum Team. To simplify logistics, it is held at the same time and location every working day of the Sprint, establishing a consistent rhythm for daily synchronization. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.
Developers have the autonomy to choose the structure and techniques they employ for the Daily Scrum, as long as it remains focused on progress toward the Sprint Goal and generates an actionable plan for the next day’s work. This promotes focus and enhances self-management within the Development Team.
Daily Scrums improve communication, identify impediments promptly, facilitate rapid decision-making, and consequently reduce the need for other meetings, streamlining communication and coordination.
The Daily Scrum is not the only opportunity for Developers to adjust their plan. They frequently engage in more detailed discussions throughout the day to adapt or replan the remaining Sprint work as needed, demonstrating continuous adaptation and collaboration.
Sprint Review: Demonstrating and Validating the Increment
The primary purpose of the Sprint Review is to inspect the Increment created during the Sprint and determine future adaptations based on feedback and insights. The Scrum Team presents the results of their work to key stakeholders, and progress toward the Product Goal is discussed collaboratively.
During the Sprint Review, the Scrum Team and stakeholders jointly review what was accomplished during the Sprint and assess any changes in the environment that may influence future work. Based on this shared understanding, attendees collaborate on determining the next steps. The Product Backlog may be adjusted to capitalize on new opportunities or address emerging challenges. The Sprint Review is intended to be a working session, encouraging active participation and feedback, rather than a passive presentation.
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 duration is typically shorter.
Sprint Retrospective: Reflecting and Improving the Process
The Sprint Retrospective is dedicated to planning ways to enhance quality and effectiveness within the Scrum Team.
The Scrum Team examines the past Sprint, focusing on individuals, interactions, processes, tools, and their Definition of Done. The specific elements inspected may vary depending on the domain of work. Assumptions that led to deviations are identified, and their origins are explored to prevent recurrence. The Scrum Team discusses what went well during the Sprint, what challenges were encountered, and how those challenges were addressed (or not addressed).
The Scrum Team identifies the most impactful improvements that can be implemented to enhance their effectiveness. The most critical improvements are prioritized and addressed as soon as possible, potentially even being added to the Sprint Backlog for the next Sprint, demonstrating a commitment to continuous improvement.
The Sprint Retrospective concludes the Sprint, marking the end of the iteration. 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: Representing Work and Value
Scrum’s artifacts represent work or value, serving as tangible representations of key information. They are designed to maximize transparency, ensuring that everyone inspecting them has a common understanding and basis for adaptation.
Each artifact is associated with a commitment that ensures it provides information that enhances transparency and focus, against which progress can be measured:
- For the Product Backlog, the commitment is the Product Goal, providing long-term direction.
- For the Sprint Backlog, the commitment is the Sprint Goal, defining the objective for the current Sprint.
- For the Increment, the commitment is the Definition of Done, establishing quality criteria.
These commitments reinforce empiricism and Scrum values for the Scrum Team and stakeholders, ensuring alignment and shared understanding.
Product Backlog: The Roadmap of Product Evolution
The Product Backlog is an evolving, ordered list of everything that is known to be needed in the product to improve it. It serves as the single source of work undertaken by the Scrum Team, providing a centralized and prioritized list of features, enhancements, and fixes.
Product Backlog items that can be realistically completed by the Scrum Team within one Sprint are considered ready for selection in Sprint Planning. They typically achieve this level of clarity and readiness through refinement activities. Product Backlog refinement is an ongoing process of breaking down and further defining Product Backlog items into smaller, more precise items. This iterative refinement involves adding details such as descriptions, order, and size estimates. The specific attributes of Product Backlog items may vary depending on the domain of work.
The Developers who will be performing the work are responsible for sizing Product Backlog items, leveraging their technical expertise. The Product Owner may influence sizing by providing context, helping Developers understand trade-offs, and ensuring alignment with product vision.
Commitment: Product Goal – The Long-Term Vision
The Product Goal describes a desired future state of the product, serving as a target for the Scrum Team to plan and work towards. The Product Goal is an integral part of the Product Backlog, providing long-term direction and context for all Product Backlog items. The rest of the Product Backlog emerges and evolves to define “what” needs to be done to achieve the Product Goal.
A product is a vehicle for delivering value. It has a clear boundary, identifiable stakeholders, and well-defined users or customers. A product can take various forms, including a service, a physical product, or something more abstract.
The Product Goal represents the long-term objective for the Scrum Team, providing a sustained focus. The Scrum Team should strive to fulfill one Product Goal before embarking on the next, maintaining a clear and consistent direction for product evolution.
Sprint Backlog: The Plan for the Sprint
The Sprint Backlog comprises 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’s a detailed guide for the current Sprint.
The Sprint Backlog is a plan developed by and for the Developers, reflecting their understanding of the work and approach. It serves as 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 dynamically updated throughout the Sprint as new information emerges and understanding evolves. It should contain sufficient detail to enable Developers to effectively inspect their progress during the Daily Scrum.
Commitment: Sprint Goal – The Sprint Objective
The Sprint Goal is the singular objective for the Sprint, providing a focused and measurable target for the Scrum Team. While the Sprint Goal is a commitment made by the Developers, it allows for flexibility in the specific work required to achieve it. The Sprint Goal fosters coherence and focus, encouraging the Scrum Team to collaborate effectively rather than working on isolated initiatives.
The Sprint Goal is defined during the Sprint Planning event and then incorporated into the Sprint Backlog, serving as a guiding principle for the Sprint. As Developers work throughout the Sprint, they continuously keep the Sprint Goal in mind. If the work deviates from initial expectations, they collaborate with the Product Owner to adjust the Sprint Backlog scope without compromising the Sprint Goal, maintaining focus on the Sprint’s primary objective.
Increment: The Tangible Result of the Sprint
An Increment is a concrete stepping stone toward the Product Goal, representing a valuable and usable piece of working product. Each Increment is additive to all preceding Increments and is thoroughly verified to ensure that all Increments function seamlessly together, creating a cohesive and integrated product. To deliver value, the Increment must be usable and meet the Definition of Done.
Multiple Increments may be created within a single Sprint, allowing for iterative value delivery. The sum of all Increments created during the Sprint is presented at the Sprint Review, providing empirical evidence of progress. However, an Increment can be delivered to stakeholders before the Sprint concludes, enabling faster value realization. The Sprint Review should not be perceived as a gate for releasing value; value delivery can occur throughout the Sprint.
Work cannot be considered part of an Increment unless it fully meets the Definition of Done, ensuring quality and completeness.
Commitment: Definition of Done – The Quality Standard
The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the required quality measures for the product. It serves as a quality guide for the Scrum Team.
The moment a Product Backlog item satisfies the Definition of Done, an Increment is created, signifying the completion of valuable work.
The Definition of Done promotes 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, ensuring that only high-quality, completed work is integrated into the product.
If a Definition of Done is already established as part of the organization’s standards, all Scrum Teams within the 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 the specific product they are developing, ensuring quality and consistency.
The Developers are responsible for ensuring that all work conforms to the Definition of Done, upholding quality standards. If multiple Scrum Teams are collaborating on the same product, they must collectively define and consistently adhere to the same Definition of Done, ensuring consistency and integration across teams.
Concluding Thoughts on the Scrum Guide
Scrum is freely available and comprehensively described in this guide. The Scrum framework, as outlined in the Scrum Guide, is immutable, meaning its core principles and structure cannot be altered. While it is possible to implement only parts of Scrum, the resulting approach would not be considered Scrum in its entirety. Scrum exists as a complete framework and functions optimally as a container for integrating other techniques, methodologies, and practices, enhancing its adaptability and effectiveness in diverse contexts.
Acknowledgements
People
Among the countless individuals who have contributed to the evolution of Scrum, special recognition is due to those who played a pivotal role in its inception: Jeff Sutherland, working with Jeff McKenna and John Scumniotales, and Ken Schwaber, collaborating with Mike Smith and Chris Martin, all of whom worked together in the early stages. Numerous others have contributed over the years, and their collective efforts have been instrumental in refining Scrum to its current state.
Scrum Guide History
Ken Schwaber and Jeff Sutherland jointly presented Scrum for the first time at the OOPSLA Conference in 1995. Their presentation documented the knowledge they had gained over the preceding years and publicly introduced the first formal definition of Scrum.
The Scrum Guide encapsulates Scrum as it has been developed, evolved, and sustained for over 30 years by Jeff Sutherland and Ken Schwaber. Other resources provide complementary patterns, processes, and insights that can enhance the Scrum framework, potentially increasing productivity, value, creativity, and satisfaction with outcomes.
A comprehensive history of Scrum is available in other publications. To acknowledge the pioneering organizations where Scrum was initially tested and validated, we recognize Individual Inc., Newspage, Fidelity Investments, and IDX (now GE Medical).
© 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.
