Scrum is a lightweight framework that helps teams and organisations generate value through adaptive solutions for complex problems. It is intentionally incomplete — it defines the minimum necessary roles, events, and artefacts, deliberately leaving space for teams to add the specific techniques, methods, and tools that work in their context.
3
Accountabilities
5
Events
3
Artefacts
5
Values
1–4w
Sprint length
2020
Latest Scrum Guide
🔄 The Sprint Cycle at a Glance
📋
Sprint Planning
Max 8hr / 4-wk sprint
⚡
Daily Scrum
15 min · every day
🚀
Sprint
1–4 weeks · fixed
🔍
Sprint Review
Max 4hr / 4-wk sprint
♻️
Retrospective
Max 3hr / 4-wk sprint
🏛 The 3 Pillars of Empiricism
👁
Transparency
The process and work must be visible to those performing and receiving it. Artefacts must be transparent to enable good decisions.
🔬
Inspection
Scrum artefacts and progress must be inspected frequently to detect problems. Events are designed specifically to provoke inspection.
🔧
Adaptation
If inspection reveals deviation, adjustment must happen as soon as possible. Scrum events are designed specifically to enable adaptation.
What Scrum is not: Scrum is not a process, technique, or definitive method. It is a framework within which you can employ various processes and techniques. The Scrum Guide intentionally has no prescribed engineering practices — those come from XP, TDD, CI/CD, and other sources.
Scrum 2020 deliberately uses the term accountabilities rather than roles — emphasising that each is a set of responsibilities, not a job title. All three accountabilities together form the Scrum Team.
🎯
Product Owner
Maximise product value
Accountable for maximising the value of the product resulting from the Scrum Team's work. Manages the Product Backlog effectively so the most valuable work is always at the top.
→ Develops and communicates the Product Goal
→ Creates and orders Product Backlog items
→ Ensures the Backlog is transparent and understood
→ Accepts or rejects Sprint output
→ The PO is one person — not a committee
⚠️ Common myth: The PO is a business analyst who writes user stories. Reality: The PO is accountable for the value of the product — a strategic, decision-making role.
🧭
Scrum Master
Servant Leader
Accountable for the Scrum Team's effectiveness. Serves the Scrum Team by coaching in self-management and cross-functionality. Serves the organisation by leading, training, and coaching Scrum adoption.
→ Facilitates Scrum events as needed
→ Removes impediments to progress
→ Coaches team on Scrum theory and practice
→ Helps the PO with Product Backlog management
→ Serves the broader organisation
→ No authority over the team — enables, not directs
⚠️ Common myth: The SM is a project manager who tracks tasks. Reality: The SM is a servant leader who enables the team — no authority, no task assignment.
⚙️
Developers
Create the Increment
Everyone in the Scrum Team who is committed to creating a usable Increment each Sprint. Not just software engineers — anyone who does work toward the Sprint Goal.
→ Create the Sprint Backlog
→ Instil quality by adhering to Definition of Done
→ Adapt plan daily toward the Sprint Goal
→ Hold each other accountable as professionals
→ Self-managing — decide internally who does what
→ Cross-functional — collectively have all the skills needed
⚠️ Common myth: Developers only means software engineers. Reality: Any person who creates value toward the Increment — designer, tester, analyst, data scientist.
👥 Scrum Team Characteristics
Small enough to be agile
10 or fewer people — typically 3–9 Developers + SM + PO
Cross-functional
All skills needed to create value in each Sprint — no external dependencies
Self-managing
Decide internally who does what, when, and how — no external direction
One product
Focused on one Product Goal, one Product Backlog, one Product Owner
Scrum prescribes 5 formal events — each is a container for inspection and adaptation. All events are time-boxed: they have a maximum duration. Missing events reduces transparency and loses the opportunity to inspect and adapt.
🚀
Sprint — The Container for All Other Events
1 to 4 weeks · fixed length · the heartbeat of Scrum
▼
Duration
1 to 4 weeks — consistent length throughout the product development lifecycle. Fixed once chosen.
Purpose
A short, fixed period during which a "Done", usable, and potentially releasable product Increment is created.
During a Sprint
No changes made that would endanger the Sprint Goal. Quality is maintained. The Product Backlog is refined as needed.
Cancellation
Only the Product Owner can cancel a Sprint — only if the Sprint Goal becomes obsolete. Very rare and disruptive.
📋
Sprint Planning
Max 8 hours for a 4-week Sprint · shorter for shorter Sprints
▼
Why this Sprint?
Define the Sprint Goal — the single objective for the Sprint. The Product Owner proposes how the product could increase value.
What can be done?
Developers select items from the Product Backlog to include. Only Developers forecast what they can accomplish.
How will it be done?
Developers plan the work needed to create an Increment that meets the Definition of Done — the Sprint Backlog is created.
Output
Sprint Goal + Sprint Backlog. The Sprint Goal provides flexibility — the team can negotiate scope to achieve it.
⚡
Daily Scrum
15 minutes · every day · same time and place · Developers only
▼
Purpose
Inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed — adjusting the upcoming planned work.
Who attends
Developers. The Scrum Master ensures it happens. The Product Owner may attend but is not required. No external attendees.
Format
Developers choose their own structure — the classic "3 questions" format is not prescribed in the 2020 Scrum Guide. Focus on the Sprint Goal, not individual status.
Common mistake
Treating it as a status report for the manager. It is for Developers to synchronise and adapt their plan — not for reporting upward.
🔍
Sprint Review
Max 4 hours for a 4-week Sprint · inspect the Increment · adapt the Product Backlog
▼
Purpose
Inspect the Sprint's outcome and determine future adaptations. The Scrum Team presents their work to stakeholders and progress toward the Product Goal is discussed.
Who attends
Entire Scrum Team + key stakeholders invited by the Product Owner. A working session — not a demo or presentation.
Output
A revised Product Backlog — defining probable items for the next Sprint. Stakeholder input shapes the next Sprint's direction.
Common mistake
Treating it as a "pass/fail demo". It is a collaborative working session — stakeholders provide input, not just approval.
♻️
Sprint Retrospective
Max 3 hours for a 4-week Sprint · improve process · closes the Sprint
▼
Purpose
Plan ways to increase quality and effectiveness. Inspect how the last Sprint went regarding individuals, interactions, processes, tools, and DoD.
Who attends
Scrum Team only — a safe space for honest reflection without external attendees.
Output
Most impactful improvements identified and added to the next Sprint Backlog. The team self-manages the improvement process.
Order
Occurs after the Sprint Review and before the next Sprint Planning. It closes the Sprint. Many teams run it immediately before next Sprint Planning.
Scrum's artefacts represent work or value and are designed to maximise transparency of key information. Each artefact has a commitment — a measurable property that provides focus and a basis for inspection.
📚
Product Backlog
An ordered list of everything that is known to be needed in the product. The single source of work for the Scrum Team. Never complete — evolves continuously. Only one Product Backlog per product, regardless of how many teams.
→ Ordered by value, risk, priority, and dependency → Items at the top are more detailed and refined → Continuously refined — Backlog Refinement → The PO is accountable for its content and ordering
Commitment: Product Goal
📋
Sprint Backlog
The Sprint Goal (why) + the Product Backlog items selected for the Sprint (what) + a plan for delivering the Increment (how). Created during Sprint Planning. Owned by Developers — updated throughout the Sprint.
→ Highly visible, real-time picture of the work → Belongs to Developers — PO cannot add to it mid-Sprint → Updated daily during Daily Scrum → Destroyed at end of Sprint — new one created each Sprint
Commitment: Sprint Goal
📦
Increment
A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments. Multiple Increments may be created within a Sprint. An Increment must be usable — not necessarily released.
→ Must meet the Definition of Done to be an Increment → Must be usable — even if the PO decides not to release it → Multiple Increments can be created per Sprint → Cumulative — builds on all prior Increments
Commitment: Definition of Done
🎯 The 3 Commitments — Added in Scrum Guide 2020
Product Goal
The long-term objective for the Scrum Team — describes a future state of the product. The team pursues one Product Goal at a time. The Product Backlog defines what will fulfil the Product Goal.
Sprint Goal
The single objective for the Sprint — provides focus and coherence for Developers. Created during Sprint Planning. Gives flexibility: scope can be negotiated while keeping the goal intact.
Definition of Done
A formal description of the state of the Increment when it meets the quality measures required for the product. Creates transparency and shared understanding of what "Done" means.
The 5 Scrum values underpin all Scrum events, roles, and artefacts. When these values are embodied and lived by the Scrum Team, the empirical Scrum pillars of Transparency, Inspection, and Adaptation come to life.
💪
Courage
Scrum Team members have the courage to do the right thing and work on tough problems — even when uncomfortable.
🎯
Focus
Everyone focuses on the work of the Sprint and the goals of the Scrum Team. Nothing outside the Sprint Goal takes priority.
🤝
Commitment
People personally commit to achieving the goals of the Scrum Team — not to a scope, but to doing their best work toward the goal.
👐
Openness
The Scrum Team and its stakeholders agree to be open about all the work and challenges with performing the work.
🙏
Respect
Team members respect each other to be capable and independent people — and are respected by those with whom they work.
🔗 Values → Pillars → Scrum
Commitment + Focus → enable Transparency — people are open about their work when they are committed and focused Openness + Courage → enable Inspection — honest inspection requires courage to share uncomfortable truths Respect → enables Adaptation — teams can adapt their ways of working when they respect each other's contributions and perspectives
Scrum and Kanban are both agile frameworks but serve different contexts. Understanding their differences helps teams and leaders choose the right approach — or combine them (Scrumban).
Dimension
Scrum
Kanban
Scrumban
Cadence
Fixed-length Sprints (1–4 weeks)
Continuous flow — no fixed iterations
Sprints optional — flow-based within sprint
Roles
3 accountabilities: PO, SM, Developers
No prescribed roles
Typically Scrum roles retained
Planning
Sprint Planning at start of each Sprint
Continuous — pull work when capacity exists
Planning triggered by low WIP
Change mid-cycle
Scope protected during Sprint
Change accepted at any time
Change managed via WIP limits
Work in progress
Sprint Backlog commitment limits scope
Explicit WIP limits per column
WIP limits + sprint cadence
Retrospectives
Prescribed at end of every Sprint
Not prescribed — done when needed
Regular retrospectives retained
Metrics
Velocity, Sprint burndown, cumulative flow
Lead time, cycle time, throughput, CFD
Mix of both
Best for
Product development, new feature delivery, cross-functional teams
The honest answer: Most teams that say they "do Scrum" actually do Scrumban — they use the Scrum ceremonies and roles but don't strictly protect Sprint scope. Both approaches work; the key is intentionality about which you're using and why.
40 flash cards covering Scrum accountabilities, events, artefacts, values, and exam-relevant knowledge. Click a card to flip it.