Foundation
Scrum Values
Without these values, Scrum is just a set of meetings. They give direction to all team work, actions, and behaviour.
Commitment
Team commits to goals and supports each other
Courage
Do the right thing; work on tough problems
Focus
Focus on Sprint work and the team's goals
Openness
Be open about all work and challenges
Respect
Respect each other as capable people
Foundation
Three Pillars of Empiricism
👁
Transparency
The process and work must be visible to those performing and receiving it.
🔍
Inspection
Artifacts and progress must be inspected frequently to detect undesirable variances.
🔄
Adaptation
If aspects deviate outside acceptable limits, the process must be adjusted as soon as possible.
Roles
Roles
The Scrum Team consists of exactly three accountabilities. No sub-teams, no hierarchies.
🎯
Product Owner
Maximises product value. Owns and orders the Product Backlog. One person, not a committee.
Role
🛡
Scrum Master
Servant-leader. Establishes Scrum, removes impediments, coaches the team and organisation.
Role
🛠
Developers
Create a usable Increment every Sprint. Self-managing. Includes testers, designers, analysts.
Role
Roles
Product Owner
Accountable for maximising the value of the product resulting from the Scrum Team's work.
Key accountabilities: → Developing and communicating the Product Goal → Creating and expressing Product Backlog items clearly → Ordering the Product Backlog → Ensuring the backlog is transparent and understood
The PO is one person, not a committee. If stakeholders want to change priorities, they must convince the Product Owner — not override them.
Roles
Scrum Master
Accountable for establishing Scrum and the Scrum Team's effectiveness. A servant-leader, not a project manager.
Serves three groups: Scrum Team → coaches self-management, removes impediments Product Owner → effective backlog techniques, stakeholder facilitation Organisation → leads Scrum adoption, advises on implementation
A Scrum Master who assigns tasks, tracks individual velocity, or reports to management is not doing the role. The SM enables the team — they do not command it.
Roles
Developers
Anyone committed to creating any aspect of a usable Increment each Sprint — engineers, testers, designers, analysts included.
Developers are self-managing — they decide internally who does what, when, and how. No one outside the team tells them how to turn backlog items into Increments.
Events
Events
All events are timeboxed opportunities to inspect and adapt. Skipping or shortening them without intent undermines Scrum.
🔁
The Sprint
The heartbeat. 1–4 weeks, fixed length. All other events happen inside it.
1–4 weeks
📋
Sprint Planning
Why, what, and how for the Sprint. Sets the Sprint Goal and Sprint Backlog.
max 8 hrs
☀️
Daily Scrum
15-minute planning event for Developers. Inspect progress toward the Sprint Goal.
15 min
🎯
Sprint Review
Inspect the Increment with stakeholders. Not a demo — a collaboration session.
max 4 hrs
🪞
Retrospective
How can we improve? Produces 1–3 actionable improvements for the next Sprint.
max 3 hrs
Events
The Sprint
⏱ 1–4 weeks · fixed length. A new Sprint starts immediately after the previous one ends.
Rules during a Sprint: → No changes that endanger the Sprint Goal → Quality does not decrease → Product Backlog is refined as needed → Scope may be renegotiated with the Product Owner
Only the Product Owner can cancel a Sprint. This happens only when the Sprint Goal becomes obsolete. It is rare and disruptive — avoid unless genuinely necessary.
Events
Sprint Planning
⏱ max 8 hours (4-week Sprint). Three topics:
1. Why → What value does this Sprint deliver? → Sprint Goal 2. What → Which backlog items are selected? → Sprint Backlog 3. How → How will the work get done? → Development plan
Events
Daily Scrum
⏱ 15 minutes · same time and place. A planning event for Developers to inspect progress toward the Sprint Goal and adapt the plan.
Common format (not mandatory): → What did I do yesterday toward the Sprint Goal? → What will I do today toward the Sprint Goal? → Are there any impediments in my way?
The Daily Scrum is not a status update to management. Managers attending and asking questions defeats its purpose entirely.
Events
Sprint Review
⏱ max 4 hours (4-week Sprint). The Scrum Team presents results to stakeholders and collaborates on what to do next.
This is not a demo. It is a working session where the whole team and stakeholders inspect the Increment and adapt the Product Backlog together.
Events
Sprint Retrospective
⏱ max 3 hours (4-week Sprint). Three questions:
→ What went well this Sprint? → What problems were encountered? → What will we improve — and how?
A retro that produces a long list but no committed actions is wasted time. End every retro with 1–3 specific, owned improvement items added to the next Sprint Backlog.
Artifacts
Artifacts
Each artifact has a commitment — a mechanism to reinforce transparency and empiricism.
📝
Product Backlog
Single source of work. Ordered by the Product Owner. Always evolving.
Commitment: Product Goal
📌
Sprint Backlog
Sprint Goal + selected items + plan. Created and owned by Developers.
Commitment: Sprint Goal
📦
Increment
Usable, potentially releasable product at the end of a Sprint. Additive to prior Increments.
Commitment: DoD
Artifacts
Definition of Done
A formal description of the state an Increment must meet to be considered complete. Non-negotiable.
Example DoD: ✓ Code reviewed by at least one other Developer ✓ Unit tests written and passing ✓ Integration tests passing ✓ No known critical bugs ✓ Documentation updated ✓ Deployed to staging environment
If an item does not meet the DoD, it cannot be presented at the Sprint Review and returns to the Product Backlog. Skipping the DoD under pressure creates technical debt.
Reference
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| SM as project manager | Assigns tasks, tracks individuals, reports upward | SM is a servant-leader; team self-manages |
| PO by committee | No one can make a decision; priorities conflict | One empowered PO owns the backlog |
| Sprint as mini-waterfall | Design sprint → dev sprint → test sprint | Each Sprint produces a shippable Increment |
| No Sprint Goal | Team works through a list with no unifying objective | Every Sprint must have a clear, meaningful goal |
| Skipping the Retro | No opportunity for process improvement | Retro is non-negotiable; improvements go to next Sprint |
| Daily Scrum as status | Developers report to managers instead of coordinating | Planning event for Developers only |
| Backlog refinement ignored | Sprint Planning becomes a discovery session | Refine continuously; 10% of capacity max |
| DoD ignored under pressure | Undone work declared Done; velocity inflated | DoD is non-negotiable; undone = back to backlog |
| Extending Sprints | Sprint extended because work isn't finished | Fixed timebox; unfinished items return to backlog |
Reference
Scrum Cheat Sheet
Roles Product Owner → maximises product value; owns the backlog Scrum Master → serves the team; removes impediments; coaches Scrum Developers → create the Increment; self-managing Events & timeboxes (4-week Sprint) Sprint → 1–4 weeks, fixed length Sprint Planning → max 8 hours Daily Scrum → 15 minutes, every day Sprint Review → max 4 hours Retrospective → max 3 hours Artifacts & commitments Product Backlog → commitment: Product Goal Sprint Backlog → commitment: Sprint Goal Increment → commitment: Definition of Done Values & pillars Values → Commitment · Courage · Focus · Openness · Respect Pillars → Transparency · Inspection · Adaptation