Fact-checked by Grok 2 weeks ago

Scrum

Scrum is a lightweight agile framework designed to help people, teams, and organizations generate value through adaptive solutions for complex adaptive problems, emphasizing empiricism and lean thinking.^[1] Developed in the early 1990s and first formally described in the 2010 Scrum Guide by Ken Schwaber and Jeff Sutherland—its originators—the framework provides a structured yet flexible approach to product development, delivery, and sustenance, particularly in software but applicable to any complex work.^[1] At its core, Scrum organizes work into time-boxed iterations called Sprints, typically lasting up to one month, during which a cross-functional Scrum Team—consisting of a Product Owner, Scrum Master, and Developers—collaborates to deliver a usable Increment of value.^[1] The Product Owner prioritizes the Product Backlog to align with the Product Goal, while the Scrum Master facilitates the process and removes impediments, and Developers self-manage to build the Increment meeting the Definition of Done.^[1] Key Events include Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective, which promote transparency, inspection, and adaptation.^[1] Scrum's Artifacts—the Product Backlog, Sprint Backlog, and Increment—ensure transparency by representing work and value, with commitments like the Product Goal, Sprint Goal, and Definition of Done providing focus and quality assurance.^[1] Underpinning the framework are five core Values: commitment, focus, openness, respect, and courage, which guide behaviors and enable successful implementation.^[1] By fostering iterative progress, empirical feedback, and team empowerment, Scrum enables organizations to respond effectively to change and deliver sustainable value in uncertain environments.^[1]

History

Origins

Scrum originated in the early 1990s as an innovative approach to software development amid frustrations with traditional waterfall methods. In 1993, Jeff Sutherland, then Chief Engineer at Easel Corporation, implemented the first Scrum team to accelerate the development of an object-oriented design and analysis tool called Object Studio.^[2] Inspired by his experience as a fighter pilot, where checklists and emergency procedures ensured precise landings under pressure, and by Hirotaka Takeuchi and Ikujiro Nonaka's 1986 article in the Harvard Business Review, 'The New New Product Development Game,' which used a rugby metaphor for holistic, overlapping product development,^[3] Sutherland adapted similar disciplined, adaptive techniques to manage software sprints, introducing tools like the burndown chart to track progress and handle disruptions effectively.^[2]^[4] This initial application involved a small team led by the first Scrum Master, Jeff McKenna, and emphasized short iterations with working code deliverables at the end of each sprint, drawing briefly on prior iterative concepts from methodologies like Rapid Application Development.^[2] Parallel to Sutherland's efforts, Ken Schwaber developed a similar framework at his company, Advanced Development Methods (ADM), in the early 1990s, applying it to complex software projects that resisted predictable planning. Schwaber's approach was grounded in complex adaptive systems theory, viewing software development as an emergent, self-organizing process influenced by chaos and uncertainty principles, such as those articulated in works on empirical control and requirements volatility.^[2]^[5] He integrated ideas from industrial research, including self-organizing teams and overlapping development phases, to create a flexible structure for handling unpredictability in product cycles.^[2] The convergence of these independent developments occurred in 1995 when Sutherland and Schwaber collaborated to present Scrum publicly for the first time at the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference in Austin, Texas, during a workshop on business object design and implementation.^[6]^[1] This presentation formalized Scrum as an agile process treating development as a controlled black box, emphasizing empiricism and incremental delivery. A key early publication from this period was Schwaber's 1995 white paper, "SCRUM Development Process," which outlined the framework's core elements, including roles, artifacts, and ceremonies, building on the OOPSLA insights to promote its adoption in software engineering.^[6]

Evolution and Standardization

The formalization of Scrum as a distinct framework began in the late 1990s, building on early implementations by Jeff Sutherland and Ken Schwaber in software development projects.^[7] In 2001, the Scrum Alliance was founded as a nonprofit organization to promote Scrum practices and provide training and certification, marking a key step in its standardization and global dissemination. The following year, in 2002, the Alliance launched the Certified ScrumMaster (CSM) training program, the first formal certification for Scrum practitioners, which has since trained over a million professionals worldwide.^[8] The official definition of Scrum was first documented in the Scrum Guide, published in February 2010 by Schwaber and Sutherland, which outlined the framework's roles, events, and artifacts to ensure consistent understanding and application.^[1] This initial version included concepts like the Chief Product Owner for large-scale efforts, which was later removed in the 2013 update to emphasize a single Product Owner per team for clearer accountability.^[9] The 2016 revision introduced Scrum's five core values—commitment, focus, openness, respect, and courage—to reinforce the framework's foundational principles without altering the core structure.^[10] Subsequent updates refined the framework iteratively. The 2020 Scrum Guide simplified the artifacts by introducing explicit commitments (Product Goal for the Product Backlog, Sprint Goal for the Sprint Backlog, and Definition of Done for the Increment) and shifted emphasis from self-organizing to self-managing teams, empowering teams to decide who does what, when, and how within the framework.^[11] Although Scrum originated in the early 1990s, predating the 2001 Agile Manifesto, the Manifesto's principles of iterative development and customer collaboration significantly boosted Scrum's adoption as a leading agile methodology.^[12] As of 2025, the Scrum Guide remains in its 2020 form, with ongoing community discussions around adaptations for hybrid and remote work environments influenced by post-COVID shifts, though no official revisions have incorporated these explicitly.^[13]

Core Principles

Empirical Process Control

Empiricism in Scrum refers to an approach that manages uncertainty through evidence-based decision-making, asserting that knowledge comes from experience and decisions are based on observed facts rather than speculation.^[1] This foundational theory is particularly suited to complex environments where predictability is low, such as software development, by treating the process as a "black box" that requires external controls due to inherent unpredictability.^[6] In contrast to defined processes like the Waterfall methodology, which assume stable conditions and set all context and deliverables upfront in a linear sequence, empirical process control in Scrum evolves plans iteratively based on emerging realities to handle changing requirements and technological variables.^[6] The three pillars upholding empirical process control in Scrum are transparency, inspection, and adaptation. Transparency ensures that the process and work remain visible to all involved, such as through clearly defined and accessible backlogs, enabling informed participation and reducing hidden risks.^[1] Inspection involves frequent and diligent examination of progress and artifacts to identify variances early, fostering a culture of continuous awareness without relying on exhaustive upfront planning.^[1] Adaptation requires prompt adjustments to processes or products whenever deviations are detected, allowing teams to respond effectively to feedback and minimize waste in uncertain settings.^[1] In software development, these pillars address the core challenges of unpredictability, where requirements often evolve and technologies shift rapidly, by prioritizing learning through experience over rigid predictions.^[14] This empirical foundation optimizes risk control and value delivery in complex projects, distinguishing Scrum from predictive methodologies that struggle with environmental changes.^[6]

Iterative and Incremental Development

Iterative development in Scrum refers to the process of repeating cycles of planning, execution, and review to progressively refine and improve the product based on feedback and learning.^[15] This method allows teams to address complexities by breaking down work into manageable iterations, enabling continuous refinement rather than a linear progression.^[1] The incremental approach complements iteration by focusing on building and delivering potentially shippable product increments at the end of each cycle, where each increment adds value and is usable in its own right.^[1] In Scrum, this means that the product grows cumulatively, with every iteration producing a complete, integrated portion that meets the definition of "Done," allowing for early validation and deployment.^[15] This combination of iterative refinement and incremental delivery forms the core of Scrum's structure for product development.^[1] The benefits of this approach include significant risk reduction through early and frequent feedback, which helps identify issues before they escalate; faster time-to-market by enabling the release of valuable features sooner; and greater adaptability to changing requirements or market conditions.^[15] For instance, teams can pivot based on real-world usage data from increments, minimizing wasted effort on unviable paths.^[1] These advantages stem from the empirical process control in Scrum, where iteration supports ongoing inspection and adaptation.^[1] Central to this methodology is the concept of time-boxing, which imposes fixed durations on iterations—typically one to four weeks—to create a predictable rhythm, enforce focus, and prevent indefinite expansion of scope.^[15] By adhering to these short, consistent time-boxes, teams maintain momentum and ensure that each cycle concludes with a tangible increment, fostering discipline and regular delivery.^[1]

Values

Commitment

In Scrum, commitment refers to the dedication of the Scrum Team members to achieving the team's goals and supporting one another in their efforts. This value emphasizes a collective responsibility to deliver high-quality increments of the product while fostering mutual support within the team. As defined in the official Scrum framework, the primary focus of commitment is on the work of the Sprint to make the best possible progress toward these goals.^[1] Commitment manifests in several key ways within the Scrum process. Team members demonstrate it by adhering to the Sprint Goal, which serves as a commitment to the specific objectives of the current Sprint and provides flexibility in how the work is accomplished. Full participation in Scrum events, such as the Daily Scrum, Sprint Planning, and Sprint Review, further embodies this value by ensuring consistent alignment and progress toward shared outcomes. Additionally, commitment extends to pursuing personal and professional growth, as team members actively engage in continuous improvement practices to enhance their contributions to the team's success.^[1]^[16] This value plays a crucial role in upholding Scrum's empiricism, the foundation of its empirical process control through transparency, inspection, and adaptation. By committing to reliable and consistent effort, the team enables effective inspection of progress during events and adaptation based on empirical feedback, thereby reducing uncertainty and promoting sustainable development. Commitment reinforces the other Scrum pillars by ensuring that artifacts like the Product Backlog, Sprint Backlog, and Increment provide clear, transparent information for decision-making.^[1]^[17] Practical examples illustrate commitment across roles. Developers commit to the Definition of Done, a shared understanding of quality criteria that must be met for each item in the Increment, ensuring that the output is potentially releasable and meets the team's standards. The Product Owner, meanwhile, commits to ongoing Product Backlog refinement, prioritizing items and maintaining clarity to support the team's focus on delivering value. These commitments collectively drive the team toward the Product Goal, the long-term objective that guides the entire product development effort.^[1]^[17] Commitment interconnects with the value of focus by directing dedicated efforts toward prioritized work, avoiding distractions that could dilute progress.^[16]

Focus

Focus in Scrum refers to the deliberate concentration of the Scrum Team's efforts on the work of the Sprint to achieve the best possible progress toward the Sprint Goal, thereby protecting the team from overcommitment and distractions that could dilute their effectiveness.^[1] This value ensures that team members prioritize high-value activities aligned with current objectives, fostering an environment where the team can deliver incremental value without unnecessary interruptions.^[16] Key practices that embody focus include the use of time-boxed events, such as the Sprint itself (typically one month or less), which limits the scope of work to prevent scope creep and external influences from derailing progress.^[1] During the Sprint, the team maintains a single focus on selected Product Backlog items, with the Scrum Master actively shielding the team from changes or distractions outside the agreed-upon goals, allowing for deep, uninterrupted work periods often structured in focused bursts like 90-minute intervals.^[18] These practices are complemented by the commitment of the team to the Sprint Goal, which drives sustained attention on prioritized deliverables.^[1] The benefits of this focus are substantial, including increased productivity through the elimination of multitasking and context switching, which can otherwise reduce efficiency by up to 20% per task due to cognitive overhead.^[19] By concentrating on fewer items at a time, teams experience reduced overhead from task-switching, leading to faster completion of work and higher quality outputs with fewer errors.^[18] Overall, this approach enhances the team's ability to generate value efficiently while minimizing waste.^[16] Focus is closely tied to Scrum artifacts, particularly through the prioritization of the Product Backlog by the Product Owner, who orders items based on value to ensure the team selects and concentrates on the most important ones during Sprint Planning.^[1] This prioritization mechanism reinforces focus by aligning the team's efforts with organizational objectives, making the Product Backlog a tool for sustained direction rather than a source of scattered attention.^[16]

Openness

Openness in Scrum refers to the Scrum Team and its stakeholders being transparent about the work accomplished and the challenges faced. This value promotes honest communication and sharing of information to build trust and enable effective collaboration.^[1] Openness is demonstrated through practices such as sharing progress updates during the Daily Scrum and Sprint Review, where the team discusses what was accomplished, what challenges arose, and how they were addressed. It also involves maintaining visible artifacts like the Product Backlog and Sprint Backlog, which provide clear insights into priorities and ongoing work. By embracing openness, the team fosters an environment where impediments can be quickly identified and resolved, supporting the pillars of empiricism.^[1] This value enhances inspection and adaptation by ensuring that all relevant information is accessible, allowing for informed decision-making and continuous improvement. Openness interconnects with respect and courage, as it requires team members to share vulnerabilities without fear of judgment.^[1]

Respect

Respect in Scrum involves Scrum Team members valuing each other as capable, independent individuals, and being treated as such by external stakeholders. This value cultivates a supportive team dynamic where diverse perspectives are appreciated, and everyone contributes to shared success.^[1] Respect manifests in behaviors such as listening actively during events, acknowledging contributions, and providing constructive feedback in retrospectives. It extends to recognizing the expertise of all roles, whether Product Owner, Scrum Master, or Developers, and avoiding hierarchical impositions that undermine self-management. By prioritizing respect, teams create psychological safety, which encourages innovation and problem-solving.^[1] Respect supports openness and commitment by ensuring that team interactions are constructive and focused on collective goals rather than individual egos. It is essential for maintaining a healthy team environment that sustains long-term productivity.^[1]

Courage

Courage in Scrum means that Scrum Team members have the bravery to do the right thing, address tough problems, and pursue innovative solutions, even when facing uncertainty or resistance. This value empowers the team to challenge the status quo and make decisions aligned with the framework's principles.^[1] Courage is exemplified by speaking up about impediments during Daily Scrums, pushing back against scope changes that threaten the Sprint Goal, or advocating for quality standards in the Definition of Done. The Scrum Master plays a key role in fostering courage by coaching the team to embrace risks inherent in adaptive work. Through courage, teams deliver value by confronting complexities head-on rather than avoiding them.^[1] This value interconnects with focus and commitment, as courageous actions ensure that efforts remain directed toward meaningful outcomes. Courage also reinforces empiricism by enabling honest inspections that lead to necessary adaptations.^[1]

Roles

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.^[1] This role focuses on ensuring that the team's efforts align with business objectives and deliver outcomes that meet user needs and stakeholder expectations.^[20] As the sole individual in this position, the Product Owner cannot share accountability with committees or multiple people, though they may delegate specific tasks while retaining overall responsibility.^[1] The primary duties of the Product Owner include managing the Product Backlog, defining the product vision through the Product Goal, and prioritizing features based on stakeholder needs.^[1] Product Backlog management entails developing and explicitly communicating the Product Goal, creating and clearly expressing Product Backlog items, ordering them to best achieve goals and missions, and ensuring the Backlog remains transparent, visible, and understandable to all.^[1] The Product Goal serves as a long-term objective for the Scrum Team, providing a "North Star" that guides decisions on what to build next.^[20] Prioritization involves assessing value, risk, dependencies, and other factors to sequence items effectively, representing diverse stakeholder interests in the Backlog.^[20] The Scrum Master may provide support to the Product Owner in these backlog management activities.^[1] The Product Owner holds authority to decide what the team builds, including the order of Product Backlog items and whether work meets the Definition of Done, thereby determining acceptability for the Increment.^[1] They represent user and stakeholder interests by accepting or rejecting completed work during the Sprint, ensuring it contributes to releasable value.^[21] This authority extends to canceling a Sprint if necessary, and their decisions must be respected organizationally, with rationale made visible through the Product Backlog and Increment.^[1] Effective Product Owners require strong business acumen to align product decisions with market and organizational strategy, excellent communication skills to articulate vision and requirements clearly, and robust decision-making abilities under uncertainty to prioritize amid evolving needs.^[22] These skills enable the Product Owner to navigate ambiguity, such as incomplete information from stakeholders, while driving value-focused outcomes.^[23] The Product Owner interacts closely with stakeholders to gather and incorporate feedback, acting as their primary voice in the Scrum Team, and collaborates with the Development Team during events like Sprint Planning and Sprint Review to clarify priorities and inspect progress.^[1] Stakeholders influence the product indirectly by convincing the Product Owner to adjust the Backlog, rather than engaging the team directly.^[1]

Scrum Master

The Scrum Master is accountable for establishing Scrum as outlined in the Scrum Guide and ensuring its effective and cohesive practice within the organization. This role embodies servant-leadership, prioritizing the removal of obstacles, the promotion of Scrum theory and values, and the coaching of the Scrum Team to achieve high performance. Unlike traditional managerial positions, the Scrum Master focuses on enabling rather than directing, fostering an environment where the team can self-organize and deliver value iteratively.^[24] Core responsibilities of the Scrum Master include coaching the Development Team on self-management and cross-functionality, facilitating Scrum events such as Sprint Planning and Daily Scrums to ensure they are productive and time-boxed, and promoting the team's adherence to the Definition of Done for high-quality Increments. By teaching Scrum practices and helping everyone understand its empirical foundations, the Scrum Master guides the team toward continuous improvement and collaboration. Additionally, the Scrum Master supports the Product Owner in effective Product Backlog management, such as through stakeholder collaboration, in a limited facilitative capacity.^[24]^[25] In the servant-leadership approach, the Scrum Master protects the team from external interruptions and distractions, shielding their focus during Sprints to maintain productivity and psychological safety. This involves creating a supportive atmosphere that encourages open communication and experimentation, while modeling behaviors aligned with Scrum values like respect and openness. The Scrum Master also identifies and resolves impediments—ranging from technical dependencies to organizational policies—that hinder the team's progress, often by influencing changes beyond the immediate team context.^[24]^[25] On an organizational level, the Scrum Master advocates for the broader adoption of Scrum by leading, training, and coaching beyond their Scrum Team, such as mentoring other teams or facilitating enterprise-wide improvements. This includes promoting Scrum understanding among stakeholders and removing systemic barriers to agility, thereby enhancing overall organizational effectiveness and cultural alignment with agile principles. Through these efforts, the Scrum Master contributes to sustained Scrum maturity across the company.^[24]^[25]

Development Team

The Development Team, now commonly referred to as Developers in contemporary Scrum frameworks, consists of professionals committed to delivering a usable product increment at the end of each Sprint.^[1] These individuals possess a diverse set of skills necessary to define, build, test, and deliver increments independently, forming a cross-functional unit without sub-teams or hierarchies.^[1] Typically comprising 3 to 9 members to maintain agility while enabling substantial progress, the team includes roles such as software developers, testers, designers, and analysts, depending on the product domain.^[1] Self-organization is a core characteristic of the Development Team, empowering members to internally determine who performs specific tasks, when, and how, free from external directives.^[1] This autonomy extends to crafting the Sprint Backlog during planning and adapting it daily to align with the Sprint Goal, fostering collaborative decision-making and collective ownership of the work.^[1] The Scrum Master may offer guidance on enhancing these dynamics, but the team retains full responsibility for its internal processes.^[1] The team holds collective accountability for the quality and completeness of the product increment, ensuring adherence to the Definition of Done—a shared agreement on the standards for releasable work.^[1] This includes instilling quality through rigorous practices, holding each other accountable as professionals, and adapting plans each day to meet objectives.^[1] Unlike individual accountability models, the emphasis is on shared responsibility, which promotes transparency and continuous improvement within the team.^[1] In practice, the Development Team collaborates intensively throughout the Sprint, participating in events like Sprint Planning to forecast and refine work items from the Product Backlog.^[1] They estimate effort using techniques such as story points or planning poker, decompose tasks into manageable units (often one day or less), and conduct daily collaborations—such as the 15-minute Daily Scrum—to inspect progress and replan as needed.^[1] These activities enable the team to adapt to changes, deliver high-value increments, and evolve their approach based on empirical feedback from each Sprint.^[1]

Events

Sprint

A Sprint is the fundamental unit of development in Scrum, serving as a time-boxed iteration that encapsulates the entire process of creating a potentially releasable Increment. It represents the heartbeat of the framework, transforming ideas into tangible value through focused, iterative work.^[1] The duration of a Sprint is fixed at one month or less, ensuring predictability and rhythm in the development cycle; this time-box begins immediately after the conclusion of the previous Sprint, promoting continuous progress without unnecessary delays. Its primary purpose is to produce a potentially releasable Increment that meets the defined quality standards, while providing a stable container for all other Scrum events, such as the Daily Scrum, to support the achievement of the overarching Product Goal. Within these boundaries, no changes are permitted that would jeopardize the Sprint Goal, and the level of quality must not decline; however, the Product Backlog may be refined as needed, and the scope of work can be clarified or renegotiated if it aligns with the goal.^[1] Central to each Sprint is the Sprint Goal, a single, concrete objective that guides the team's efforts and fosters flexibility in how the work is completed. This measurable aim ensures alignment and focus throughout the iteration, allowing the Developers to adapt tactics while delivering a cohesive outcome. Sprints encompass events like the Daily Scrum to facilitate daily coordination toward this goal. Cancellation of a Sprint is rare and occurs only if the Sprint Goal becomes obsolete due to external factors, such as market shifts; authority to cancel rests solely with the Product Owner, after which the team returns to the Product Backlog to start a new Sprint.^[1]

Sprint Planning

Sprint Planning is a collaborative event in the Scrum framework that initiates the Sprint by defining the work to be performed. It involves the entire Scrum Team, including the Product Owner, Scrum Master, and Developers, to ensure alignment on objectives and feasibility. The event is time-boxed to a maximum of eight hours for a one-month Sprint, with proportionally less time for shorter Sprints, allowing the team to focus efficiently without unnecessary prolongation.^[26] The planning session is structured around three key topics to guide the discussion. First, the team addresses "Why is this Sprint valuable?" by collaboratively defining the Sprint Goal, which articulates the specific objective that provides focus and value for the iteration. Second, under "What can be done this Sprint?", the Product Owner presents the prioritized Product Backlog items, and the Developers select those that can be completed within the Sprint to achieve the Sprint Goal, forecasting the team's capacity based on historical velocity and current availability. Third, the "How will the chosen work get done?" topic involves the Developers breaking down the selected items into actionable tasks, estimating effort, and creating a plan to deliver a potentially releasable Increment by the Sprint's end. The Product Owner ensures clarity on backlog items throughout, while the Scrum Master facilitates the process to keep it productive and within the time-box.^[26] Key inputs to Sprint Planning include the Product Backlog, the Product Goal, the team's past performance (such as velocity from previous Sprints), current capacity, and the Definition of Done. These elements enable realistic forecasting and selection. The primary outputs are the Sprint Goal, the set of selected Product Backlog items for the Sprint, and the Sprint Backlog, which comprises the plan for delivering the Increment, including task breakdowns and estimates. Estimation during the "How" phase often employs techniques like Planning Poker, a consensus-based method using cards with Fibonacci-like numbers (e.g., 1, 2, 3, 5, 8) to reveal estimates simultaneously and foster discussion on uncertainties. This technique, popularized by Mike Cohn, helps the Developers arrive at relative effort estimates collaboratively.^[26]^[27] By the conclusion of Sprint Planning, the Sprint Goal must be finalized and committed to by the team, serving as a commitment that guides all subsequent work during the Sprint. This event ensures transparency and shared understanding, setting a strong foundation for the iteration while empowering the Developers to self-manage in executing the plan.^[26]

Daily Scrum

The Daily Scrum is a key event in the Scrum framework, serving as a daily synchronization mechanism for the Developers to inspect progress toward the Sprint Goal and adapt their work plan accordingly. Held every working day during the Sprint, it fosters improved communication among team members, enables early identification of impediments, and supports adaptive planning to maintain momentum toward the overall Sprint objectives. This event contributes to broader Sprint progress tracking by providing regular touchpoints for alignment without disrupting the flow of daily work.^[26] Time-boxed to 15 minutes, the Daily Scrum is typically conducted in a standing format to encourage brevity and focus, preventing it from extending into detailed discussions. The Developers—comprising those who do the work—gather at the same time and place each day to minimize logistical complexity and build routine. While the Product Owner and Scrum Master may participate if they are actively contributing to Sprint Backlog items, the event is primarily led by the Developers, with others observing silently to avoid derailing the team's focus. Problem-solving or in-depth planning is explicitly deferred to follow-up conversations outside the meeting, ensuring the Daily Scrum remains a high-level coordination tool rather than a forum for resolution.^[26]^[28] The structure of the Daily Scrum is flexible, allowing the Developers to select techniques that best suit their needs, as long as the focus remains on progress inspection and creating an actionable plan for the next 24 hours. A widely adopted format involves each Developer addressing three key questions: What did I do yesterday that helped the team meet the Sprint Goal? What will I do today to help the team meet the Sprint Goal? Are there any impediments blocking my progress? This approach enhances transparency, promotes quick adaptation of the Sprint Backlog, and highlights issues for timely intervention by the Scrum Master. Empirical studies indicate that effective Daily Scrums, when conducted per guidelines, positively influence team psychological safety, work satisfaction, and perceptions of performance through improved collaboration and reflexivity.^[26]^[29]^[30]

Sprint Review

The Sprint Review is a formal event at the end of the Sprint where the Scrum Team and stakeholders inspect the outcomes of the Sprint and adapt the Product Backlog accordingly.^[1] This event emphasizes collaboration to align on progress toward the Product Goal and incorporate feedback to maximize value delivery.^[1] The Sprint Review is time-boxed to a maximum of four hours for a one-month Sprint, with proportionally shorter durations for briefer Sprints, allowing for an efficient yet thorough collaborative discussion.^[1] Participants include the entire Scrum Team—comprising the Product Owner, Scrum Master, and Developers—along with key stakeholders such as customers, users, or other interested parties who provide input on the product's direction.^[1] The Product Owner typically leads discussions on the next priorities, ensuring that feedback informs backlog adjustments.^[1] Key activities during the Sprint Review involve demonstrating the Product Increment, which represents the potentially releasable work completed during the Sprint.^[1] The team reviews what was accomplished, assesses progress toward the Sprint Goal and overall Product Goal, and discusses any changes in the broader environment, market, or product strategy that may influence future work.^[1] This is structured as an interactive working session rather than a passive presentation, fostering dialogue to gather insights and identify new opportunities.^[1] The primary outcomes of the Sprint Review are an adjusted Product Backlog that reflects stakeholder feedback and new insights, along with a shared understanding of the product's trajectory.^[1] These adaptations ensure that the Scrum Team can respond effectively to evolving requirements while maintaining focus on delivering incremental value.^[1]

Sprint Retrospective

The Sprint Retrospective is the concluding event of the Sprint in the Scrum framework, where the Scrum Team collectively inspects the outcomes of the previous Sprint to identify and plan improvements. Its primary purpose is to enhance the quality and effectiveness of future work by examining elements such as individual contributions, team interactions, processes, tools, and adherence to the Definition of Done.^[1] This introspection builds directly on the experiences from the Sprint, enabling the team to adapt without revisiting product-specific details. The event is time-boxed to a maximum of three hours for a one-month Sprint, scaled proportionally shorter for briefer Sprints, ensuring it remains focused and efficient.^[1] To promote open and honest dialogue, the Retrospective is conducted in a confidential, blameless environment that prioritizes psychological safety, allowing team members to share observations without fear of reprisal.^[31] The structure typically involves the team discussing what aspects of the Sprint went well, identifying problems encountered and how they were addressed (or not), and determining the most helpful changes to implement next.^[1] These discussions often follow a phased approach—gathering data on events and feelings, generating insights into underlying causes, deciding on specific improvements, and committing to action items—which draws from established retrospective facilitation methods to drive actionable outcomes.^[32] Resulting improvements may be incorporated into the Product Backlog or directly actioned by the team to address immediate process gaps.^[1] The Scrum Master plays a key facilitative role, ensuring the event occurs as scheduled, remains productive, and adheres to its introspective focus, while modeling behaviors that reinforce psychological safety and accountability for follow-through on decided actions.^[33] By avoiding blame and encouraging collective ownership, the facilitator helps mitigate common dysfunctions like finger-pointing, which can undermine the session's value.^[34] This servant-leadership approach empowers the entire Scrum Team to co-facilitate, fostering a collaborative atmosphere.^[1] The benefits of the Sprint Retrospective lie in its promotion of continuous improvement, leading to refined team dynamics, streamlined processes, and heightened overall efficiency over successive Sprints.^[1] Regular practice of this event has been shown to build resilience and adaptability within teams, as evidenced by its integration into high-performing Agile organizations where it contributes to sustained productivity gains.^[35] Ultimately, it transforms reflections into tangible enhancements, aligning with Scrum's empirical pillars of transparency, inspection, and adaptation.^[1]

Artifacts

Product Backlog

The Product Backlog is an emergent, ordered list of everything that might be needed to improve the product, serving as the single source of work undertaken by the Scrum Team.^[1] It is dynamic and evolves over time as the product and the environment change, incorporating features, fixes, enhancements, and other requirements that emerge from stakeholder input, market shifts, or team insights.^[1] The Product Goal, a commitment within the Product Backlog, describes a future state of the product that guides the team's efforts and provides a target for planning.^[1] The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team's work and thus owns the effective management of the Product Backlog.^[1] This includes developing and clearly communicating the Product Goal; creating, maintaining, and ordering Product Backlog items based on factors such as business value, risk, return on investment, and dependencies; and ensuring the Backlog's transparency so that items are visible, refined, and understandable to those who will inspect it.^[1]^[36] Each item typically includes a clear description, an order relative to other items, and an estimate of its size or effort, often expressed in story points or hours to facilitate prioritization and selection.^[1] Product Backlog refinement is an ongoing process in which the Scrum Team, primarily the Developers under the Product Owner's guidance, adds details, estimates, and order to items to ensure they are sufficiently clear and ready for future Sprints.^[1] The team decides how and when to conduct refinement to balance preparation with delivery.^[1] This activity helps maintain the Backlog's usability by breaking down large items, clarifying acceptance criteria, and addressing uncertainties. As the team's understanding of the product and its requirements deepens, new items continually emerge and are added to the Product Backlog, reflecting the adaptive nature of Scrum in complex environments.^[1] During Sprint Planning, the Scrum Team selects items from the top of this ordered list to commit to for the upcoming Sprint.^[1]

Sprint Backlog

The Sprint Backlog is a key artifact in Scrum that represents the Developers' selected and planned work for the upcoming Sprint. It consists of the Sprint Goal, which defines the purpose of the Sprint; a set of Product Backlog items selected to achieve that goal; and an actionable plan outlining the tasks, estimates, and steps required to deliver an Increment.^[1] Ownership of the Sprint Backlog lies entirely with the Developers, who create it during Sprint Planning and maintain it throughout the Sprint as their commitment to completing the work. The team is responsible for breaking down the selected Product Backlog items into a detailed plan, including tasks and time estimates, to guide daily execution while ensuring alignment with the Sprint Goal. This ownership empowers the team to self-organize and make decisions about how to accomplish the work without external micromanagement.^[1] The Sprint Backlog provides high visibility into the team's progress, serving as a real-time snapshot of the remaining work that is updated daily during the Daily Scrum. As the team progresses, they refine the plan by adding, removing, or re-estimating tasks based on actual impediments or new insights, ensuring the artifact remains a living document that reflects current realities. This daily inspection helps the team identify and address any blockers promptly, fostering transparency within the Scrum Team and stakeholders.^[1] As an emergent plan, the Sprint Backlog is designed for flexibility, allowing the Developers to adapt to changing circumstances or additional information without altering the Sprint Goal. While the overall scope may be refined through negotiation with the Product Owner if necessary, the focus remains on delivering value toward the goal, enabling the team to respond effectively to uncertainties inherent in complex work environments. This adaptability distinguishes the Sprint Backlog from more rigid planning approaches, promoting iterative improvement and resilience in delivery.^[1]

Product Increment

The Product Increment is a concrete stepping stone toward the Product Goal, consisting of the sum of all Product Backlog items completed during a Sprint and all previous Increments. It represents the usable version of the product at the end of the Sprint, ensuring that it delivers tangible value to stakeholders.^[1] To qualify as part of the Product Increment, all work must adhere to the Definition of Done, a formal description of the quality measures required for the product, which typically includes requirements such as testing, integration, and documentation. This ensures that the Increment is thoroughly verified and additive to prior Increments, forming a cohesive whole where all elements work together without unresolved issues. If work does not meet the Definition of Done, it returns to the Product Backlog for future consideration.^[1] The Product Increment embodies concrete progress toward the overarching Product Goal, serving as a releasable artifact that may be delivered to stakeholders at any time, even before the Sprint concludes. Across Sprints, all Increments maintain consistent quality standards through a shared Definition of Done, whether defined organizationally or by the Scrum Team, preventing variability in product reliability. It is typically demoed during the Sprint Review to gather feedback and inspect progress.^[1]

Implementation

Adopting Scrum

Adopting Scrum begins with a structured approach to implementation, emphasizing the framework's core elements such as roles and events to ensure teams can generate value through adaptive solutions. Organizations typically start by assessing readiness and committing to the framework in its entirety, as partial implementations undermine its empirical foundation. This involves leadership creating a shared vision, engaging coaches for education, and developing a roadmap with milestones.^[1]^[37] Key initial steps include training teams on Scrum practices to build practical understanding and alignment. Recommended training, such as the Applying Professional Scrum course, helps teams apply concepts beyond theory, fostering collaboration and addressing knowledge gaps identified as a major barrier in 53% of transformations. Concurrently, defining roles is essential: the Product Owner manages the Product Backlog to maximize value, the Scrum Master coaches on Scrum adoption and removes impediments, and Developers form a cross-functional team to deliver increments. These roles must be clearly assigned to empower self-managing teams of typically 10 or fewer members.^[38]^[37]^[1] Following role definition, organizations set up the first Sprint by creating a Product Backlog with prioritized items, forming cross-functional teams aligned to value areas, and conducting initial Sprint Planning to select workable items. Tools like Jira facilitate this by centralizing backlog management, estimation, and prioritization, enabling transparent tracking of progress. The first Sprint serves as a pilot to test empiricism through events like Daily Scrum and Sprint Review, allowing immediate inspection and adaptation.^[39]^[40] Cultural shifts are critical during adoption, moving from traditional command-and-control management to servant leadership and team empowerment, where decision-making decentralizes to those closest to the work. This requires fostering Scrum values like commitment and respect to build trust and cross-functional collaboration, often through coaching to address resistance from ingrained hierarchical behaviors. Retrospectives help surface and resolve such resistance by identifying root causes, such as unfamiliarity with incremental delivery.^[41]^[16]^[38] To measure success, organizations track metrics that support empiricism and continuous improvement, including velocity as a planning tool to forecast capacity without equating it to productivity, burndown charts to monitor Sprint progress against commitments, and customer satisfaction indicators tied to delivered value. These metrics, used judiciously, help optimize outcomes rather than enforce rigid targets.^[42]^[43]^[37] Common challenges in adoption include incomplete implementations known as "ScrumButs," where teams modify the framework without addressing underlying issues, leading to superficial practices that fail to deliver benefits. Another pitfall is overemphasizing ceremonies like Daily Scrum without grasping their purpose in enabling inspection and adaptation, resulting in ritualistic adherence rather than empirical decision-making. Overcoming these requires dedicated coaching and a focus on systemic improvements to avoid local optimizations that hinder overall agility.^[44]^[38]

Scaling Frameworks

Scaling frameworks extend the Scrum methodology to large organizations by integrating multiple Scrum teams while minimizing additions to the core framework, building on foundational Scrum events and artifacts to address multi-team coordination for complex products. These frameworks aim to deliver integrated increments at scale without sacrificing agility, though they vary in structure and emphasis. The Nexus framework, introduced by Scrum.org co-founder Ken Schwaber, supports the scaling of Scrum across 3 to 9 teams developing a single product. It introduces the Nexus Integration Team, comprising representatives from each Scrum Team, to oversee cross-team dependencies and ensure a potentially shippable Nexus Increment at the end of each Sprint. Key extensions include the Nexus Sprint Backlog for shared items, Cross-Team Refinement to manage the Product Backlog, and events such as the Nexus Daily Scrum and Nexus Sprint Review to facilitate integration and transparency.^[45] The Scaled Agile Framework (SAFe), developed by Scaled Agile Inc., provides a comprehensive approach for enterprise-scale agile adoption, organizing 50 to 125 individuals into Agile Release Trains (ARTs) that align teams around common missions and deliverables. ARTs operate on fixed cadences with Program Increment (PI) planning events to synchronize priorities, dependencies, and objectives across teams, incorporating roles like Release Train Engineers and Product Management to support portfolio-level strategy. SAFe emphasizes Lean-Agile principles, integrating Scrum with Kanban and DevOps practices for business agility.^[46] Large-Scale Scrum (LeSS), created by Craig Larman and Bas Vodde, focuses on simplicity and organizational simplicity when scaling Scrum to 2 to 8 teams (or more in LeSS Huge configurations) for one product. It retains a single Product Backlog and Product Owner, employing feature-driven cross-functional teams to avoid silos, with coordination achieved through multi-team events like the Overall Product Backlog Refinement, Sprint Review, and Retrospective, rather than additional layers of hierarchy. LeSS principles stress whole-product focus, customer-centricity, and continuous improvement to preserve Scrum's empirical nature at scale.^[47] Despite their benefits, scaling frameworks present challenges including coordination overhead from synchronizing multiple teams, dependency management across interdependent workstreams, and maintaining agility amid growing organizational complexity. Research identifies issues such as aligning structures with agile principles, balancing team autonomy with enterprise alignment, and effectively scaling practices without introducing bureaucracy, which can hinder responsiveness if not addressed through targeted training and cultural shifts.^[48]^[49] Evidence of adoption underscores the frameworks' impact, with scaled agile practices widely implemented in large enterprises; for example, over 70% of Fortune 100 companies utilized SAFe as their primary scaling method in 2025. The State of SAFe Report 2025 further reports that 68% of organizations experienced increased employee satisfaction following implementation, reflecting broad acceptance among high-impact contributors to agile scaling.^[50]^[51]

References

[1]
Scrum Guide | Scrum Guides
### Summary of the 2020 Scrum Guide Introduction (Sections: Purpose, Definition, Scrum Team, Events, Artifacts, Values)
[2]
[PDF] THE SCRUM PAPERS: - Object Technology Jeff Sutherland
... Scrum was launched at Easel Corporation in 1993 with the help of Jeff McKenna and John Scumniotales, the first Scrum Master. Results exceeded all ...Missing: fighter | Show results with:fighter
[3]
Scrum and Fighter Aircraft - Object Technology Jeff Sutherland
Jul 6, 2008 · In 1993 at Easel Corporation when we started the first Scrum, I thought the ScrumMaster needed to see how to land a Sprint on a date, ...Missing: origins checklist
[4]
Project management with Scrum - BCS, The Chartered Institute for IT
Nov 16, 2007 · History of scrum. At Advanced Development Methods (ADM), Ken Schwaber identified product functionality that could be built in monthly cycles ...<|control11|><|separator|>
[5]
[PDF] SCRUM Development Process - Object Technology Jeff Sutherland
In this paper we introduce a development process, SCRUM, that treats major portions of systems development as a controlled black box. We relate this to ...
[6]
Scrum: A Brief History of a Long-Lived Hype
Dec 18, 2020 · The first, official version of the Scrum Guide was released in February 2010. ... “The Scrum Guide” by Ken Schwaber and Jeff Sutherland (2009, ...
[7]
Certified ScrumMaster (CSM) Certification - Scrum Alliance
The CSM course provides a solid understanding of scrum, covering the framework, team accountabilities, events, and artifacts, and is well-known to employers.Missing: 2002 | Show results with:2002
[8]
Official Scrum Guides (Current & Past) - Mitch Lacey
Explore the official Scrum Guides from 2010 to present and see how the agile framework has evolved. Learn all about Scrum here.
[9]
[PDF] July 2016 - Scrum Guides
This Guide contains the definition of Scrum. This definition consists of Scrum's roles, events, artifacts, and the rules that bind them together. Ken Schwaber ...
[10]
Scrum Guide Revisions
Scrum is a framework for developing and sustaining complex products. The Scrum Guide contains the official definition of Scrum as authored by Ken Schwaber and
[11]
Agile and Scrum: Unravelling the Misconceptions
Jul 25, 2023 · Scrum aligns with Agile principles by promoting iterative development, frequent inspections, and continuous adaptation. It provides a framework ...
[12]
Download - Scrum Guides
Download the official Scrum Guide Revision History. Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland.
[13]
“I Don't Care About Scrum, I Do Care About Empiricism” | Scrum.org
Sep 1, 2023 · These are the three pillars of Scrum: transparency, inspection, and adaptation. It's these three pillars that allow empirical process control ...
[14]
Iterative vs. Incremental Development - Scrum Inc.
Incremental development is iterating on the whole thing (each iteration is a minimal useable feature set that is potentially shippable).
[15]
The Scrum Values
The Scrum Values are: Commitment - Each Scrum Team member commits to achieving the team's goals and to support each other.Applying the Scrum Values · Exploring the Scrum Values... · Poster
[16]
Scrum Guide 2020 Update - Commitments
Nov 18, 2020 · Commitment is one of the five Scrum Values. It is described in the Scrum Guide: “The Scrum Team commits to achieving its goals and supporting ...
[17]
Multitasking - Scrum Inc.
Teams can get multiple projects done in less time when they can focus on just one project at a time. The quality of their work also increases. Just like ...Missing: benefits | Show results with:benefits
[18]
Simplifying Work: The Path to Greater Productivity - Scrum.org
Nov 18, 2023 · Key topics covered in this exploration include the 'Less is More' principle, the cost of multitasking, the impact of context switching on productivity.Missing: benefits reduced
[19]
What is a Product Owner? - Scrum.org
A Product Owner is accountable for maximizing product value, owns the product vision, and guides the team towards a shared understanding of the product's value.
[20]
https://www.scrum.org/resources/what-product-owner
[21]
Agile scrum roles and responsibilities - Atlassian
The product owner: Setting clear direction. Scrum product owners understand the customer and business requirements, then create and manage the product backlog ...
[22]
Scrum Product Owner Skills in 2025 (Top + Most Underrated ... - Teal
Scrum Product Owners need to possess strong business acumen and analytical thinking abilities. ... Decision-Making Under Uncertainty; Time Management and ...
[23]
The Scrum Guide
You can read and download the Scrum Guide here. This site contains both the 2020 and 2017 versions of the Scrum Guide. Find a series of resources that ...
[24]
What is a Scrum Master?
The Scrum Master is accountable for establishing Scrum. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team ...
[25]
[PDF] Ken Schwaber & Jeff Sutherland - Scrum Guides
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results ...
[26]
Planning Poker: An Agile Estimating and Planning Technique
Sep 4, 2025 · Planning Poker is a consensus-based technique for agile estimating. It is a fun and engaging way for teams to apply relative estimates to planned work.
[27]
What Is the Daily Scrum? | A Guide to the Daily Event | Scrum Alliance
The daily scrum is a brief daily event to inspect progress toward the sprint goal. You may have heard it referred to as a daily standup.
[28]
Importance of Daily Scrum Meeting - SCRUMstudy
Jan 4, 2023 · This meeting is considered to be a “work-centric” feedback circle that team members use to communicate and evaluate progress, identify impediments.Missing: scholarly | Show results with:scholarly
[29]
Relations between daily stand-up meetings, work satisfaction, and ...
The practice of DSM is especially prominent in agile Scrum frameworks, where the so-called “Daily Scrum” represents one of the core meeting routines (Schwaber & ...
[30]
Scrum Requires Psychological Safety
Jan 17, 2023 · For Scrum to be truly successful Scrum absolutely requires psychological safety to be established both inside and outside of the Scrum Team.
[31]
Sprint Retrospective: How to Hold an Effective Meeting - Atlassian
A sprint retrospective gives you an opportunity to review your latest ... (This is key to developing psychological safety and a blameless culture.) To ...
[32]
Making Your Sprint Retrospectives More Effective - Scrum.org
The Sprint Retrospective turns into a “blame game” where the focus is on ... Encourage strong psychological safety and a culture of radical ...
[33]
21 Sprint Retrospective Anti-Patterns - Scrum.org
Nov 25, 2019 · Sprint Retrospective Anti-Patterns of the Scrum Master ... No psychological safety: The retrospective is an endless cycle of blame and finger- ...
[34]
Quickstart To Improve Your Team's Psychological Safety - Scrum.org
May 2, 2022 · So what can you do when psychological safety is low? We share three short formats that easily fit inside a Sprint Retrospective. Their purpose ...
[35]
Ordering the Product Backlog - Scrum.org
Aug 28, 2023 · They take various factors into consideration when ordering the Product Backlog such as business value, risk, return on investment (ROI), ...
[36]
The Stages of Agile Transformation: Moving from Theory To Practice
May 28, 2023 · The stages of Agile transformation are: Awareness, Adoption, Optimization, and Scaling.
[37]
Common Issues Facing New Scrum Teams (and How to Overcome ...
Nov 6, 2024 · I recommend that teams adopting Scrum should take the Applying Professional Scrum course together. This course can help the team start off on ...
[38]
Planning an Adoption With Scrum Patterns
Jan 4, 2020 · Start by choosing Conway's Law, then get management support, create a Product Backlog, define Value Areas, and create Cross-Functional Teams. ...
[39]
Nine best Scrum tools to master project management - Atlassian
Jira makes sprint planning easier by putting the backlog at the center. It helps the team estimate stories, adjust scope, and prioritize issues in one location.
[40]
What Is Agile Transformation—And Why It Matters Now More Than ...
Jun 23, 2025 · Leadership shifts from command-and-control to servant leadership. Decision-making becomes decentralized, empowering those closest to the ...
[41]
Myth: Velocity is Productivity - Scrum.org
Velocity is a planning tool, not a measure of productivity, and is an arbitrary measure that can be gamed, potentially leading to poor quality.
[42]
Moving Beyond Velocity - Scrum On Training
Jul 29, 2019 · When I ask them about what their team is measuring, the most common answers I hear are velocity, story points, and burn-down charts. Makes sense ...
[43]
Stop Blaming Frameworks, Improve Adoptions - Scrum.org
Aug 9, 2020 · From what I see, organizations are full of superficial Agile/Lean adoptions. You must have come across ScrumButs ...
[44]
The Nexus™ Guide - Scrum.org
Nexus is a framework that drives to the heart of scaling by minimizing cross-team dependencies and integration issues.
[45]
What is SAFe - Framework For Business Agility - Scaled Agile
SAFe is the world's most trusted system for business agility because it works: it's trusted, customizable, and sustainable.Benefits of SAFe · Learn more · For Enterprises
[46]
Introduction to LeSS - Large Scale Scrum (LeSS)
Rather, LeSS is about figuring out how to apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply as possible.
[47]
[1901.08130] Implementing Large-Scale Agile Frameworks - arXiv
Jan 23, 2019 · This article identifies nine challenges associated with implementing SAFe, Scrum-at-Scale, Spotify, LeSS, Nexus, and other mixed or customised large-scale ...
[48]
https://arxiv.org/abs/1901.08130
[49]
Scaled Agile Framework 2025 (SAFe Agile) - A Complete Guide to ...
In 2025, over 70% of Fortune 100 companies use SAFe Agile as their primary scaling method (Scaled Agile Inc., 2024). The framework continues to grow in ...Missing: statistics | Show results with:statistics
[50]
State of Safe Report 2025 - Scaled Agile
SAFe implementation support 72% of organizations found Scaled Agile learning resources to be very or extremely useful in their adoption of SAFe.Missing: statistics Fortune 500