i

Description

Gravure ancienne d'une mêlée de rugby en train de se former

Source

auteur non indiqué · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Scrum, the Framework (Scrum Guide 2020)

You will be able to describe Scrum as defined by the Scrum Guide 2020: empirical theory, values, team, roles, five events, three artifacts and their commitments.

In brief

• You will be able to describe Scrum as defined by the Scrum Guide 2020: empirical theory, values, team, roles, five events, three artifacts and their commitments.
• You will distinguish what the Guide prescribes (the framework, intentionally minimal) from what practice adds (user stories, points, velocity: none of that is in the Guide).
• You will be able to read an expert's subtleties: why Sprint Review is not a validation demo, why the retrospective is the engine of the framework, what “usable increment” means.
• You will be able to identify what Scrum is not (a complete project management method, a control tool, a schedule).
• Implementations and pitfalls are in Scrum in Practice; BI application is in Scrum and data.

Source and status. Reference text: The Scrum Guide (Ken Schwaber and Jeff Sutherland, November 2020, scrumguides.org, translated into French). Verification (status 2026-10): the 2020 version remains the current published version; no more recent revision had been confirmed at the time of writing. The wording below is the author's paraphrase, not quotations; only the official text is authoritative.

On this page

1. 🟢 Beginner — Scrum in one page
   1. The elements at a glance
2. 🟢 Beginner — Empirical theory: three pillars
3. 🟢 Beginner — The five values
4. 🟢 Novice — The Scrum Team
   1. One team, not sub-teams
   2. The term “Developers”
5. 🟢 Novice — The three accountabilities
   1. Product Owner
   2. Scrum Master
   3. Developers
   4. Summary table of accountabilities
6. 🟡 Practical — The five events
7. 🟡 Practice — The Sprint
   1. Why a fixed duration
   2. Canceling a Sprint
8. 🟡 Practice — Sprint Planning
   1. Capacity and forecasting
9. 🟡 Practice — Daily Scrum
10. 🟡 Practice — Sprint Review
11. 🟡 Practice — Sprint Retrospective
12. 🟡 Practice — The Three Artifacts and Their Commitments
    1. Product Backlog
    2. Sprint Backlog
    3. Increment
13. 🟡 Practice — Product Goal
14. 🟡 Practice — Sprint Goal
15. 🟡 Practice — Definition of Done
16. 🔴 Expert — Expert Readings of the Guide
    1. 1. Scrum is an empirical process control framework, not a plan
    2. 2. The asymmetry “firm goal, flexible scope”
    3. 3. “Does everything visible have the same status?”
    4. 4. Increment and deployment: two distinct concepts
    5. 5. Self-management does not mean no constraints
    6. 6. The underestimated role of the Scrum Master: organizational change agent
    7. 7. The apparent contradiction: “one Sprint, one team, one Product Goal”
    8. 8. Predictability: through duration, not through control
17. 🔴 Expert — What the Guide Does Not Say
18. 🔴 Expert — What Scrum Is Not
19. 🔴 Expert — Guide Evolution: 2010 → 2017 → 2020
20. Metrics: Scrum by Selected Criteria
21. AI Contribution
22. See also

Level: 🟢→🔴

🟢 Beginner — Scrum in one page#

Scrum is a lightweight framework (framework) that helps people, teams, and organizations create value by delivering adaptive solutions to complex problems. Scrum is a framework, not a complete method: other processes and techniques are used within it. The Guide says it is intentionally incomplete: it defines only the parts required to implement Scrum theory.

The principle: a single cross-functional team delivers a usable Increment at short, regular intervals (the Sprints, one month or less). At the end of each Sprint, the team inspects what was produced and how it worked, then adapts.

The elements at a glance#

🟢 Beginner — Empirical theory: three pillars#

Scrum is based on empiricism (knowledge comes from experience; decisions are made from what we observe) and Lean thinking (reduce waste, focus on what matters). It opposes the idea that everything can be predicted in a complex problem (see the Cynefin framework in Project Management Fundamentals). Its approach is iterative and incremental to optimize predictability and control risk.

Three pillars support any empirical process control implementation:

These three pillars are interdependent: transparency makes inspection possible, inspection makes adaptation relevant; without adaptation, inspection is only an observation. Scrum's five events are designed as opportunities for inspection and adaptation.

The Guide also indicates that if you change Scrum's rules, the framework can lose coherence: “Scrum is only Scrum” in its entirety, which allows isolated elements to be adopted, but the Guide says full benefit comes from the whole. See ScrumBut for common drifts.

🟢 Beginner — The five values#

The values are not decorative: they describe the behavior without which the pillars collapse. The Guide states that team members learn and explore these values by working with the events and artifacts, and that decisions, actions, and the way Scrum is used must reinforce these values, not weaken them.

🟢 Novice — The Scrum Team#

One team, not sub-teams#

The fundamental unit of Scrum is a small team: one Scrum Master, one Product Owner, and Developers. There are no sub-teams or hierarchies within the Scrum Team: it is a single unit devoted to the same objective, the Product Goal.

Characteristics described by the Guide:

• Cross-functional: together, members have all the skills needed to create value every Sprint.
• Self-managing (self-managing): they decide internally who does what, when, and how. The 2020 Guide replaced “self-organizing” with “self-managing” to emphasize this point: the team does not just organize itself, it decides.
• Size: generally 10 people or fewer. The larger the team gets, the more complex communication becomes; beyond that, it is better to have multiple teams around the same product (same Product Goal, same Product Backlog, same PO).
• Responsible for all product-related activities: stakeholder collaboration, verification, maintenance, operations, experimentation, research and development, and everything else required.

The term “Developers”#

In the 2020 Guide, Developers refers to the people who commit to creating any aspect of a usable Increment each Sprint: software developers, but also analysts, testers, data specialists, BI specialists, UX specialists, etc. The term is therefore not limited to programmers. The exact skills vary by domain. The 2020 Guide dropped the phrase “Development Team” to remove the idea that a separate sub-team exists.

🟢 Novice — The three accountabilities#

The Guide talks about accountabilities rather than roles: what each person must answer for. One point to watch: accountability = answerability (duty to report), stronger than responsibility.

Product Owner#

Accountable for maximizing the value of the product resulting from the Scrum Team’s work. How to achieve this varies greatly across organizations. The PO is accountable (and may delegate work, but remains solely accountable) for the effective management of the Product Backlog:

• developing and explicitly communicating the Product Goal;
• creating and clearly communicating Product Backlog items;
• ordering Product Backlog items;
• ensuring the Product Backlog is transparent, visible, and understood.

The PO is one person, not a committee. For their authority to be real, the entire organization must respect their decisions, visible in the Product Backlog’s content and ordering and in the Increment inspected at Sprint Review. Stakeholders can request changes by convincing the PO, not by bypassing them.

Scrum Master#

Accountable for establishing Scrum as defined in the Guide, by helping everyone understand Scrum theory and practice, both within the team and across the organization. Accountable for the Scrum Team’s effectiveness, by helping it improve its practices within Scrum. This is a true leader who serves (true leader who serves) the team and the organization.

They serve:

The Scrum Master is neither a project manager, nor a meeting secretary, nor a process controller: they do not assign work, do not manage scheduling, and do not do individual progress reporting.

Developers#

Accountable for:

• creating a plan for the Sprint: the Sprint Backlog;
• instilling quality by adhering to a Definition of Done;
• adapting their plan every day toward the Sprint Goal;
• holding each other accountable as professionals.

They are the ones who estimate (the Guide specifies that Developers size the work) and decide the amount of work they can commit to delivering: neither the PO nor the SM imposes the volume.

Summary table of accountabilities#

🟡 Practical — The five events#

Scrum events create regularity and minimize the need for unplanned meetings. Each is a formal opportunity to inspect and adapt an artifact. They are held within their timebox (maximum duration) and, ideally, at the same time and place to reduce complexity. The Sprint is the container for the others.

For a shorter Sprint, events are generally shorter too (proportionally). The durations above are maximums, not targets.

🟡 Practice — The Sprint#

The heart of Scrum, the Sprint is an event of one month or less, with a consistent duration, during which ideas are turned into value. A new Sprint starts immediately after the previous one ends. All work needed to achieve the Product Goal (planning, daily development, review, retrospective) happens within Sprints.

During the Sprint:

• no changes are made that would put the Sprint Goal at risk;
• quality does not decrease;
• the Product Backlog is refined as needed;
• the scope may be clarified and renegotiated with the PO as more is learned.

Why a fixed duration#

A Sprint with a consistent duration creates a rhythm: the team learns its capacity, stakeholders know when they will get information, and predictability emerges. Short Sprints: more learning cycles, with risk limited to less than one month of cost. The Guide allows “one month or less”; most teams choose one to two weeks (an order of magnitude from practice, not a Guide rule).

Canceling a Sprint#

A Sprint can be canceled before the end of its timebox, only by the Product Owner, typically when the Sprint Goal has become obsolete (organizational direction change, market or technology shift). This is rare, costly (all planning work is lost), and disruptive; items already completed and compliant with the DoD are reviewed, and the rest is put back into the Product Backlog. Short Sprints are better than cancellation.

🟡 Practice — Sprint Planning#

Sprint Planning initiates the Sprint by defining the work to be done. This plan is the result of the collaborative work of the entire Scrum Team. The PO ensures participants are ready to discuss the most important Product Backlog items and how they relate to the Product Goal. The Scrum Team may invite others for advice.

The Guide structures Planning around three topics:

The Sprint Goal, the selected items, and the plan to deliver them together form the Sprint Backlog.

Capacity and forecasting#

The Guide prescribes neither velocity nor story points. Developers use what they know about their capacity (availability, vacations, dependencies) and their history to forecast. Detailed estimation techniques are covered in Scrum in Practice.

🟡 Practice — Daily Scrum#

Purpose: inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed by adjusting upcoming planned work.

• 15 minutes, every working day of the Sprint, at the same time and place to reduce complexity.
• Participants: Developers. If the PO or SM are actively working on Sprint Backlog items, they participate as Developers.
• The structure is flexible: Developers choose the format (the 2020 Guide removed the three ritual questions “what did I do yesterday? what will I do today? what impediments do I have?” — often kept out of habit, but not prescribed), as long as it focuses on progress toward the Sprint Goal and produces an action plan for the next day.
• It improves communication, identifies obstacles, promotes rapid decision-making, and thus removes the need for other meetings.
• It is not the only time to adjust the plan: Developers often meet right after for detailed discussions.

🟡 Practice — Sprint Review#

Purpose: inspect the Sprint outcome and determine future adaptations. The Scrum Team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed.

Flow described by the Guide: the Scrum Team and stakeholders review what was accomplished in the Sprint and what changed in their environment; on that basis, participants collaborate to determine what to do next. The Product Backlog may be adjusted to capture new opportunities. This is a working session, not a presentation: the Guide specifies it must not be limited to a demo. It includes a review of trends (timeline, budget, what is likely to be delivered) and the timeline.

🟡 Practice — Sprint Retrospective#

Purpose: plan ways to increase quality and effectiveness. The Scrum Team inspects how the Sprint went regarding people, interactions, processes, tools, and the Definition of Done. It identifies what worked well, problems encountered, how they were (or were not) resolved, and selects the most useful changes. The most impactful improvements are adopted as quickly as possible; they may even be added to the next Sprint's Sprint Backlog.

It concludes the Sprint; 3 hours max for a one-month Sprint; it takes place after the Review and before the next Sprint.

🟡 Practice — The Three Artifacts and Their Commitments#

Scrum artifacts represent work or value. They are designed to maximize transparency of key information. Each contains a commitment that improves transparency and focus:

Product Backlog#

An emergent, ordered list of what is needed to improve the product. The single source of work undertaken by the Scrum Team. Items small enough to be completed within a Sprint are considered ready to be selected in Planning, generally after refinement activities.

Refinement is the activity of further breaking down and defining Product Backlog items into smaller, more precise items. It is a continuous activity: details, descriptions, order, and size are added. Attributes vary by domain. The Developers are responsible for sizing; the PO can help by clarifying and arbitrating. The 2017 Guide stated that refinement should not exceed about 10% of Developers' capacity; the 2020 Guide no longer mentions this (this range remains a common practical benchmark).

The 2020 Guide adds: “Product Goal,” “the Product Backlog evolves as the product and environment evolve; it is alive.” A Product Backlog is never complete.

Sprint Backlog#

Composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). It is a plan by and for the Developers, a highly visible, real-time picture of planned work, updated throughout the Sprint as learning occurs. It must contain enough detail for progress to be inspectable during the Daily Scrum.

Increment#

An Increment is a concrete step toward the Product Goal. Each Increment is additive to all previous Increments and thoroughly verified, to ensure that all Increments work together. To provide value, the Increment must be usable. Multiple Increments can be created in the same Sprint, and their sum is presented at the Sprint Review. Work can only be considered part of an Increment if it meets the Definition of Done. An item that does not meet it cannot be released or presented in Review; it returns to the Product Backlog.

🟡 Practice — Product Goal#

The Product Goal describes a future state of the product that can serve as a planning target for the Scrum Team. It is in the Product Backlog: the rest of the backlog emerges to define what fulfills the Product Goal.

• Only one at a time: the Scrum Team must fulfill or abandon one objective before adopting another.
• It is the team's long-term commitment, and the team must be able to say whether it has achieved it.
• A product is a vehicle for delivering value: it has clear boundaries, identified stakeholders, and well-defined users or customers; it can be a service, a physical product, or a more abstract object.

🟡 Practice — Sprint Goal#

The Sprint Goal is the Sprint's single objective. Although it is a commitment by the Developers, it offers flexibility regarding the exact work needed to achieve it. It creates coherence and focus, encouraging the team to work together rather than on separate initiatives. It is created during Sprint Planning and added to the Sprint Backlog. If the work turns out to be different from what the Developers expected, they collaborate with the PO to negotiate the scope of the Sprint Backlog, without affecting the Sprint Goal.

🟡 Practice — Definition of Done#

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the DoD, an Increment is born.

• It creates a shared understanding of what “done” means: transparency.
• If an Increment's DoD is part of the organization's standards, all Scrum Teams must follow it at minimum. Otherwise, the Scrum Team must create one suited to the product.
• The Developers must comply with it; if multiple Scrum Teams work together on one product, they must define and follow the same DoD.
• It evolves: at each retrospective, the team can tighten its DoD; it never relaxes it to hit a date (that would destroy transparency).

A DoD suited to data is detailed in Scrum and Data; the distinction from Definition of Ready is in Scrum in Practice.

🔴 Expert — Expert Readings of the Guide#

1. Scrum is an empirical process control framework, not a plan#

A close reading of the Guide shows that almost everything in Scrum serves one single idea: shortening the feedback loop so that inspection leads to adaptation. Events are not meetings but learning synchronization points; the Sprint is a risk boundary (at worst, you lose one Sprint); the DoD is a quality boundary (nothing less than “usable”); the Sprint Goal is a degree of freedom (scope flexibility, firmness of intent).

2. The asymmetry “firm goal, flexible scope”#

One of Scrum’s deepest moves: you fix time and quality and negotiate scope. The Product Owner can change the Sprint Backlog content if the goal is threatened; Developers can reduce scope to preserve the DoD. This contradicts the predictive reflex (fixed scope, variable quality) and explains why Scrum is misunderstood in organizations that contract for scope.

3. “Does everything visible have the same status?”#

The Guide does not define a “nearly done” state. An item is Done or it is not: this prevents the “90% done” pattern, a classic illusion that hides remaining work. The operational consequence: slice work so each item fits within one Sprint and is completed rather than starting lots of things.

4. Increment and deployment: two distinct concepts#

The Increment must be usable; production release remains a PO decision (the Guide does not say “every Sprint”). Continuous deployment teams often publish several times a day (several Increments per Sprint), others deliver at Sprint end; others still accumulate several Sprints before a commercial release (the case of datamarts delivered in kits). In all cases, the Increment exists every Sprint, and it is potentially releasable: quality is the same as if it were going to production. The question of delivery frequency is addressed in CI/CD: Continuous Integration and Continuous Delivery and CI/CD for data: foundations, datamarts, pipelines, and reports.

5. Self-management does not mean no constraints#

Self-management operates within a framework: the Product Goal, the DoD, the organization’s standards. The team decides how, work allocation, and quantity; it does not decide value on its own (PO), nor does it bypass standards. It is also accountable: autonomy is inseparable from transparency and inspection.

6. The underestimated role of the Scrum Master: organizational change agent#

The 2020 Guide explicitly broadens the SM beyond the team: they help the organization adopt Scrum, remove barriers between stakeholders and teams, and advise on planning. That is why a purely “meeting facilitator” SM is considered a drift (see anti-patterns).

7. The apparent contradiction: “one Sprint, one team, one Product Goal”#

Several teams on one product: same Product Backlog, same PO, same DoD, one integrated Increment (see scaling). Only one Product Goal at a time is a powerful filter against diffusion: “multiple priorities” actually means “no priority.”

8. Predictability: through duration, not through control#

Scrum produces predictability through regularity (cadence, constant quality, learning capacity), not through a detailed plan. Long-term forecasts are made on ranges (intervals) drawn from historical data, updated every Sprint. See probabilistic forecasting (Monte Carlo on throughput) in Scrum in Practice.

🔴 Expert — What the Guide Does Not Say#

A large number of widespread practices associated with Scrum are not part of the Guide. Knowing this helps avoid blaming Scrum for what is a local convention, and avoids imposing personal preference as a “Scrum rule.”

The Guide also says nothing about:

• contracts (how to contract for a product with variable scope; see Scrum and contracts);
• distributed teams (see remote);
• technical debt, except through the DoD;
• domain-specific constraints: data, hardware, regulatory (see Scrum et data).

This incompleteness is a design choice: the Guide lets the team choose techniques as long as principles are respected. It also creates a gray zone where consultants, certifications, and competing frameworks thrive.

🔴 Expert — What Scrum Is Not#

🔴 Expert — Guide Evolution: 2010 → 2017 → 2020#

The Guide was first published in 2010, then revised in 2011, 2013, 2016, 2017, and 2020. The summary below covers the most significant 2020 changes (based on public release notes and community experience; for exact details, refer to the Guide):

The 2016–2017 revisions had already added values (2016) and clarified the DoD. What has always remained at the core: timebox, three pillars, three responsibilities. Be cautious with any claim that “Scrum has changed in nature”: the 2020 version removes prescription rather than adding it.

Metrics: Scrum by Selected Criteria#

Expert assessments, contextual (see Rating). Rating context: team of 5 to 9 people, evolving product, available sponsor; for a regulated project with fixed scope or a team of 2 people, ratings shift.

AI Contribution#

Example prompt: “Here is our Product Goal and our last five Sprint Goals. Tell me which ones are disguised item lists and propose an outcome-oriented rewording.”

What AI does not replace: mutual commitment, the courage to say no, the PO's judgment on value, Developers' responsibility for quality, trust. AI summaries made in place of conversation destroy the transparency they claim to serve. See AI in Service of Project Management (General Then Data) and AI in Planning and Version Control Tools.

See also#

• Prerequisite: Project Management Fundamentals (lifecycle, Cynefin, value).
• Next: Scrum in Practice (user stories, estimation, anti-patterns, scaling) and Scrum Applied to Data, BI, and Datamarts.
• Other Agile and Lean frameworks: Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…); comparison: Comparison of Project Management Methods; selection: Choosing Your Method and Hybridizing.
• Implementation tools: Azure DevOps Server (ex-TFS) in Depth, Jira In Depth and Alternatives, Project Metrics and Reporting.
• Measure your practice: Governance and Steering (GOU), Team and Collaboration (EQU), Continuous Improvement and Learning (AMC).
• Terms: Glossary.

✻ Written by Claude Sonnet 5.5