i

Description

Un tableau blanc couvert de notes adhésives réparties en colonnes

Source

無聊龍 · original page

Licence

CC0 Public domain

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

Scrum in Practice

You will know how to maintain a living Product Backlog, write testable user stories (INVEST, acceptance criteria), and split them vertically.

In brief

• You will know how to maintain a living Product Backlog, write testable user stories (INVEST, acceptance criteria), and split them vertically.
• You will know how to estimate in three ways (points, relative size, flow / #NoEstimates), use velocity without misusing it, and read flow metrics.
• You will know how to distinguish Definition of Ready and Definition of Done, facilitate planning and a retrospective that changes something.
• You will know how to recognize anti-patterns (ScrumBut, Scrumerfall…), set up a team, work remotely, scale, and contract.
• You will leave with a list of 30 pitfalls and a /5 rating grid.
• The framework itself is in Scrum, the framework (Scrum Guide 2020); BI application is in Scrum Applied to Data, BI, and the Datamart.

On this page

1. 🟢 Novice — The Product Backlog Day to Day
   1. What a good backlog looks like: “DEEP”
   2. Item types and mix
   3. Does the Product Owner “write” or “own”?
2. 🟢 Novice — User Stories and INVEST
   1. The INVEST criterion (Bill Wake)
   2. The case of technical and data stories
3. 🟢 Novice — Acceptance Criteria
4. 🟢 Novice — Splitting a story
   1. The principle: the vertical slice
   2. Nine splitting patterns (inspired by Richard Lawrence)
5. 🟡 Practice — Refinement (refinement)
   1. An effective session
   2. How much “ready” backlog?
6. 🟡 Practice — Estimation: points, flow, #NoEstimates
   1. 1. Story points
   2. 2. Flow-based forecasting (without points)
   3. 3. #NoEstimates
   4. Estimating data work: specifics
7. 🟡 Practice — Velocity and its abuses
8. 🟡 Practice — Useful metrics
9. 🟡 Practice — Definition of Ready vs. Definition of Done
10. 🟡 Practice — Planning a Sprint
    1. Common-sense rules
11. 🟡 Practice — The retrospective that actually changes something
    1. Typical structure (60 to 90 minutes for a 2-week Sprint)
    2. Formats
    3. The five causes of a useless retro
12. 🟡 Practice — Setting up a Scrum team
    1. Prerequisites
    2. Startup sequence (4 to 6 weeks)
    3. Roles: combinations and sizes
    4. Training without dogma
13. 🔴 Expert — Anti-patterns and ScrumBut
    1. When to abandon Scrum
14. 🔴 Expert — Remote Scrum
15. 🔴 Expert — Scaling Up
    1. Reduce dependencies rather than coordinate them
16. 🔴 Expert — Scrum and contracts
17. 🔴 Expert — Thirty pitfalls
18. Metrics: ratings /5
19. AI contribution
20. See also

Level: 🟢→🔴

🟢 Novice — The Product Backlog Day to Day#

The Product Backlog is the ordered list of everything that could improve the product (framework: Scrum, the framework (Scrum Guide 2020)). In practice, it includes features, fixes, technical improvements, experiments/spikes, and operations work. It is neither an unlimited idea warehouse nor a requirements specification.

What a good backlog looks like: “DEEP”#

Roman Pichler and Mike Cohn popularized the mnemonic DEEP:

Item types and mix#

Does the Product Owner “write” or “own”?#

The PO is accountable for the backlog, but does not have to write everything. Developers, the business, and the SM can propose items; the PO sorts, orders, and says no. A backlog managed like an inbox for requests is a symptom: ordering means giving things up.

🟢 Novice — User Stories and INVEST#

A user story describes a need from the user’s point of view, briefly, as an invitation to conversation. Ron Jeffries summarized the “3 Cs”: Card (a card, not a contract), Conversation (the real content is in discussion), Confirmation (acceptance criteria). It is not in the Scrum Guide (see what the Guide does not say).

Common template:

The INVEST criterion (Bill Wake)#

The case of technical and data stories#

“Valuable” is tricky for infrastructure work: loading a fact table, optimizing an index. Two schools:

1. Avoid purely technical stories: carry them through a value story (“see revenue by customer” includes loading the fact table). Value is pulled downward by usage.
2. Allow technical items that are explicitly justified (debt, risk, prerequisite), but keep them rare, small, and tied to an objective.

This tension is central in BI; it is addressed in Scrum Applied to Data, BI, and the Datamart. Other forms besides “As a”: Job Stories (“when [situation], I want [motivation], so I can [expected outcome]”), use cases, hypotheses (“we believe that…”). The form does not matter as long as the why and the confirmation are there.

🟢 Novice — Acceptance Criteria#

Acceptance criteria bound a story: what must be demonstrated to call it complete for that story. They are distinct from the Definition of Done, which applies to all stories (see DoR vs DoD).

Two common forms:

Feature: Monthly revenue by customer
  Scenario: Customer with two invoices in the month
    Given a customer "C-100" with invoices 1,200.00 and 300.00 in March 2026
    When I display March 2026 revenue for "C-100"
    Then the displayed value is 1,500.00
  Scenario: Customer with no sales
    Given a customer "C-200" with no invoice in March 2026
    When I display March 2026 revenue
    Then "C-200" appears with 0.00

Scenarios translated into tests (SQL, DAX, comparison query) become executable regression tests run at every release — the basis for number testing. See Testing and Reliability of Numbers.

🟢 Novice — Splitting a story#

A story that's too large doesn't fit in a Sprint, can only be tested at the end, and hides uncertainty. Splitting is the most valuable refinement move.

The principle: the vertical slice#

A vertical slice goes through all layers (source → transformation → model → reporting) to deliver a small piece of usable value. The opposite is the horizontal slice: “the entire extraction layer first, then the entire model, then all reports,” which delivers nothing usable until the end.

Nine splitting patterns (inspired by Richard Lawrence)#

🟡 Practice — Refinement (refinement)#

Refinement is continuous and the responsibility of the Scrum Team (see artifacts). In practice, most teams schedule one or two sessions per Sprint (30 to 90 minutes), in addition to ongoing clarification. The Guide mandates nothing: this is practice.

An effective session#

1. Prepare: the PO selects 5 to 8 items from the top of the backlog and shares them in advance.
2. Understand: the why first, then concrete examples (use numbers and real cases).
3. Split: if we can't say “it fits in a Sprint,” we split it.
4. Criteria: define acceptance criteria, edge cases, dependencies.
5. Estimate (if estimating): quickly, relatively.
6. Identify unknowns: is a spike needed? data to verify? expert to invite?

How much “ready” backlog?#

A benchmark: about two Sprints worth of ready items at the top of the backlog, no more (obsolescence, waste), no less (improvised Planning). If the top of the backlog depends on external answers (business trade-offs, source access), start pursuing them early, because wait time is the blocker, not size.

🟡 Practice — Estimation: points, flow, #NoEstimates#

Estimation is a decision tool, not a commitment. Its goal is to forecast (by what date, with how much scope) and to inform trade-offs (value/effort ratio). The Guide only says that Developers size the work.

1. Story points#

We measure relative effort (complexity, uncertainty, volume), not hours, using a discrete scale (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20…) to reflect increasing uncertainty.

2. Flow-based forecasting (without points)#

Instead of estimating each item, measure throughput (number of items completed per period) and cycle time (time between “started” and “done”). Assumption: if items are split to roughly the same size, counting is enough.

Probabilistic forecasting by Monte Carlo simulation: randomly sample from throughput history to simulate the future N times, and read percentiles instead of a single date.

(Illustrative values, order of magnitude.) Advantages: no point debates, few estimation meetings, honest result on uncertainty. Limits: requires history, similarly sized items, and a stable system.

3. #NoEstimates#

A movement launched by Woody Zuill and Vasco Duarte, according to which effort estimation can be reduced or removed: split into small items, measure throughput, forecast by counting, and focus on decision-making (continue or not) rather than precision. It's not “never forecast” but “don't waste time estimating what can be measured.” A common criticism: decision-makers want a date and a cost before starting; the answer is a range and reassessment milestones.

Estimating data work: specifics#

• Data volume and uncertainty: effort depends less on lines of code than on the state of the source (quality, documentation). The same item “add a field” can be 1 hour or 3 days depending on whether the data exists cleanly. Hence the value of a prior spike (Scrum Applied to Data, BI, and the Datamart).
• Machine time: a consolidation that takes hours is not work time, but it does limit test cadence. Estimate both effort and processing delay.

🟡 Practice — Velocity and its abuses#

Velocity is the sum of the points for Done items (compliant with the DoD) during a Sprint. A rolling average over three to five Sprints is used to forecast Sprint capacity or the delivery date of an estimated backlog.

Legitimate use: mid-term forecasting by the team itself; detection of drift (sudden drop: issue to investigate, not punish); Sprint Planning calibration.

🟡 Practice — Useful metrics#

Few metrics, read as trends, never as individual targets. Overall software delivery metrics (DORA) are presented in CI/CD; management reporting in Project Metrics and Reporting.

Common visualizations: burndown (remaining Sprint work; used to spot drift, not punish), burnup (work completed and scope, avoids confusion when scope changes), cumulative flow diagram (CFD: reveals bottlenecks), cycle-time histogram, cycle-time scatterplot (items completed over time with percentiles).

🟡 Practice — Definition of Ready vs. Definition of Done#

A typical DoR: value understood; acceptance criteria written; dependencies known; estimable; fits in one Sprint; test data available. Use it as a question checklist (supports conversation), not as a contract that lets the team reject any imperfect item: the Guide does not define it, and an overly rigid DoR recreates predictive siloing (“you did not deliver a complete specification”).

A typical DoD for software: code reviewed; unit and integration tests passing; no known blocking defect; documentation up to date; automated deployment to the acceptance testing environment; acceptance criteria verified. For data, see DoD data.

🟡 Practice — Planning a Sprint#

The conceptual flow is in Sprint Planning. Here is an operational template of 2 hours for a 2-week Sprint (durations are indicative; the Guide gives a maximum of 8 h for one month).

Common-sense rules#

• Do not overload: target a realistic workload (for example 70–80% of gross capacity, order of magnitude); surprises always happen.
• Keep slack for support, debt, and defects.
• Plan stretch items: at the end of the list, “if we have time” items (without counting them in the commitment).
• The Sprint Goal is the contract; the item list is negotiable.
• If an item spills over: do not “automatically carry it over”; split it again and understand why.

🟡 Practice — The retrospective that actually changes something#

The goal is described in Sprint Retrospective. Here's how to make it useful.

Typical structure (60 to 90 minutes for a 2-week Sprint)#

Formats#

The five causes of a useless retro#

1. No action or too many actions (>3) that are never tracked.
2. Same topics every time, no progress: the cause is probably outside the team's control — the SM must escalate (see responsibilities).
3. Lack of safety: the manager is in the room, nobody talks.
4. Identical format forever: fatigue. Vary it.
5. Actions with no owner or due date.

🟡 Practice — Setting up a Scrum team#

Prerequisites#

Startup sequence (4 to 6 weeks)#

Roles: combinations and sizes#

Training without dogma#

Training (SM, PO, Developers, stakeholders) is an investment, but on-the-ground coaching matters more than certification (PSM/PSPO from Scrum.org, CSM/CSPO from Scrum Alliance: their value varies by provider and trainer; they are signals, not guarantees of competence). Also train management: without sponsors who accept transparency, the team hits a ceiling.

🔴 Expert — Anti-patterns and ScrumBut#

ScrumBut (“Scrum, but...”) refers to partial or modified adoption that removes the very parts that expose problems (“we do Scrum, but we don't do retrospectives, because...” ). The term comes from Ken Schwaber and the “ScrumBut test.” This is not a judgment on flexibility: it is the loss of transparency Scrum is meant to produce.

When to abandon Scrum#

Scrum is not always the right tool. Signals: support / maintenance work with continuous flow and priorities that change hourly (Kanban is a better fit); a one-person team; strong regulatory constraints where documentary evidence is paramount (hybrid); no real PO. Changing method is a legitimate move, not a failure. See Choosing Your Method and Hybridizing and the Comparison of Project Management Methods.

🔴 Expert — Remote Scrum#

Distributed or hybrid teams have become common. Scrum works remotely, but certain implicit conditions (spontaneous communication, shared board) must be made explicit.

🔴 Expert — Scaling Up#

When the product outgrows what a team of fewer than ten people can handle, you add teams on the same product. Principle of caution: do not scale before you have one team that works; multiplying a bad practice multiplies debt.

Reduce dependencies rather than coordinate them#

The three levers in order of effectiveness: (1) eliminate the dependency (component teams aligned to value, domain-level data autonomy); (2) make it explicit and planned (dependency map, interface contracts); (3) coordinate it (meetings, bridges). For a BI team consuming a source managed elsewhere, lever 2 takes shape as a data contract — see Data Sources and Contracts.

🔴 Expert — Scrum and contracts#

A contract with fixed scope, fixed price, fixed date does not align well with a framework where scope varies. Options, from most rigid to most flexible:

Useful clauses: definition of a baseline (“Minimum Viable Product”) and target scope; right to reorder the backlog at no cost within a defined framework; Definition of Done attached to the contract (contractualized quality); client participation (client-side PO); exit conditions at each Sprint or milestone; code and documentation ownership.

For a company delivering its product to clients as versioned installation kits, contracting focuses on the version and the delivery schedule; changes to the internal backlog do not need to be contracted client by client. See Choosing Your Method and Hybridizing for alignment with version governance.

🔴 Expert — Thirty pitfalls#

Format: pitfall → consequence → remedy. Many are detailed above; the list serves as an audit checklist (to use in a quarterly retrospective).

Around the backlog and stories

1. Backlog graveyard → noise, loss of focus → expiration and deletion.
2. Technical-task stories without value → false progress → link to usage or justify explicitly.
3. Missing acceptance criteria → conflictual acceptance testing → write them before the Sprint.
4. Criteria = solution → team loses autonomy → describe observable behavior.
5. Stories too large → “almost done” items at the end → vertical slicing.
6. Estimating the entire backlog → waste → estimate only the top.
7. Three-level priorities (high/medium/low) → everything is “high” → strict ordering.

Around the Sprint and events

8. Sprint without a goal → catch-all list → Sprint Goal first.
9. Overcommitment → recurring failure, demotivation → realistic capacity, buffer.
10. Scope change during Sprint without renegotiation → loss of trust → go through the PO; the goal takes priority.
11. Automatic carryover of items → false rhythm → re-splitting.
12. Daily over 15 minutes → detailed topics in-session → “parking lot,” then separate conversation.
13. Review without stakeholders → no feedback → invite, prepare.
14. Retro with no action or follow-up → cynicism → 1–3 actions, owners.
15. Sprint too long → slow learning loop → shorten, split.

Around roles

16. Absent PO → blockers and rework → mandate and dedicated time.
17. PO dictating the technical solution → loss of quality and engagement → PO defines what/why, Developers define how.
18. SM acting as project manager → passive team → servant role.
19. Manager assigning tasks → end of self-management → let the team distribute work.
20. Fragmented part-time team → context-switching costs → stable team.

Around quality and measurement

21. Weak or variable DoD → accumulated debt → honest DoD, tightened in retro.
22. Stabilization Sprint → deferred quality → integrate testing into the Sprint.
23. Velocity as a goal → inflation → remove the target.
24. Comparing teams → sterile competition → compare outcomes.
25. Activity metrics (lines of code, tickets) → bad behavior → measure outcomes and flow.
26. Denied technical debt → slowdown → dedicate part of capacity.

Around the organization

27. Predictive governance left intact → Scrumerfall → adapt milestones and reporting (see Choosing Your Method and Hybridizing).
28. Premature scaling → organizational debt → first, one team that works.
29. Tool before practice → process frozen by the tool → practices first.
30. Change not supported by leadership → return to old habits → sponsor who accepts transparency and self-management.

Cross-functional pitfalls across all methods are in Pitfalls and Good Practices in Project Management (Cross-Functional Synthesis).

Metrics: ratings /5#

Contextual expert assessments (see Rating). Context: team of 5–9 people, software or BI product with continuous evolution. This is about rating the practices in this file, not Scrum overall (see Scrum, the framework).

AI contribution#

Prompt examples:

• “Here is a story and its criteria. List the missing edge cases (null values, duplicates, multiple languages, high volume) and propose a Given-When-Then scenario for each.”
• “Here is the export of start/end dates for the last 80 tickets. Calculate cycle time percentiles and propose an SLE. Show the script.”

What AI does not replace: conversation with the user, priority decisions, understanding hidden business rules, the accountability of the DoD. Specific risk: plausible but wrong stories and criteria (invented business rules) that go unnoticed because they are well written; and the hidden debt of abundant backlogs that no one owns. See AI for Project Management (General Then Data) and AI in Planning and Version Control Tools.

See also#

• Framework: Scrum, the framework (Scrum Guide 2020); foundation: Project Management Fundamentals.
• Application: Scrum Applied to Data, BI, and the Datamart; dedicated methods: Methods Specific to Data Projects.
• Alternatives and hybridization: Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…), Comparison of Project Management Methods, Choosing Your Method and Hybridizing.
• Delivery: CI/CD: Continuous Integration and Continuous Delivery, CI/CD for data: foundations, datamarts, pipelines, and reports.
• Tools: Project Planning and Tracking Tools: Overview, Azure DevOps Server (formerly TFS) In Depth.
• Matrices: Planning and Estimation (PLA), Scope and Requirements Management (PER), Quality and UAT (QUA).
• Glossary: Glossary.

✻ Written by Claude Sonnet 5.5