A chronological view of the full Scrum cycle — groundwork, then each event in order. Complements scrum.md (which is the reference card for roles/events/artifacts). Terminology follows the Scrum Guide 2020.
The Big Picture
Scrum is iterative. You don't plan the whole project up front — you work in fixed-length Sprints (1–4 weeks, most teams use 2). Each Sprint produces a usable Increment, and the team inspects and adapts at the end before starting the next.
Three pillars hold it together: transparency, inspection, adaptation.
The framework has exactly three parts — accountabilities (PO, Scrum Master, Developers), artifacts (Product Backlog, Sprint Backlog, Increment), and events (Sprint, Planning, Daily Scrum, Review, Retrospective). Everything below maps to one of those.
Phase 1 — Inception & Backlog Setup
The groundwork that exists before and between Sprints. Some is one-time; some is continuous.
Product vision & brainstorming
Before anything enters the backlog, the Scrum Team and stakeholders align on what is being built and why. Rough output is expected — ideas, user needs, problems to solve.
User stories
Ideas become user stories — small, user-centric descriptions of value. The template:
As a user persona, I want goal so that benefit.
Stories too large for a single Sprint are Epics; they get split during refinement.
Each story needs Acceptance Criteria (AC) — testable conditions that prove the story is complete.
INVEST — the quick checklist for a healthy story:
- Independent — can be built without waiting on another story
- Negotiable — details are open until refinement
- Valuable — delivers value to a user or the business
- Estimable — the team can size it
- Small — fits in one Sprint
- Testable — has clear AC
Product Backlog Refinement
Ongoing activity (not a fixed event). The Scrum Team:
- Splits Epics into stories
- Clarifies AC
- Re-orders items by value
- Removes items that no longer matter
- Estimates upcoming items
Goal: keep the top of the backlog Sprint-ready. Typically ≤ 10% of Developers' capacity.
Estimation — story points & Planning Poker
Teams estimate relative effort, not hours. A story point bundles complexity + effort + uncertainty into one number.
Why points, not hours? Humans are poor at absolute time estimates but decent at relative comparison ("this is roughly twice as hard as that").
Most teams use a Fibonacci-like scale: 1, 2, 3, 5, 8, 13, 20, 40, 100. The gaps widen on purpose — the larger something is, the less precisely you can estimate it.
Planning Poker:
- PO reads a story aloud.
- The team discusses briefly.
- Everyone privately picks a card with their estimate.
- All reveal simultaneously (prevents anchoring).
- If estimates diverge, the highest and lowest explain their reasoning.
- Re-vote until the team converges.
A wide spread usually means someone knows something the others don't — surfacing that is the real value.
Phase 2 — Sprint Planning
The kickoff event for each Sprint. The 2020 Guide structures it around three topics:
- Why is this Sprint valuable? → the team agrees on the Sprint Goal
- What can be done? → Developers select Product Backlog items
- How will the chosen work get done? → planning + breaking stories into tasks
Also part of Planning:
- Capacity check — account for PTO, holidays, on-call. Velocity (see below) is the historical anchor, capacity adjusts it.
- Tasking — Developers decompose stories into technical sub-tasks (implementation, review, testing, deploy).
Output: a committed Sprint Backlog and a clear Sprint Goal.
Time-box: ~2h per week of Sprint (so ~4h for a 2-week Sprint).
Phase 3 — Active Sprint
Once the Sprint starts, scope is locked. New urgent requests go to the Product Backlog, not into the current Sprint Backlog. The Sprint Goal stays fixed; the Sprint Backlog can flex as Developers learn more.
Daily Scrum
A 15-minute time-box, same time and place daily. It's a planning event for Developers — not a status report to the Scrum Master or PO. The 2020 Guide dropped the three prescribed questions; any structure is fine as long as it advances the Sprint Goal.
The norm: detailed problem-solving happens after the Daily Scrum, not inside it. Architectural debate gets tabled offline.
Work in progress
Tracked on a Scrum/task board (To Do → In Progress → Done) and often a burndown chart. Refinement of future Sprint items continues quietly in the background.
Phase 4 — Tracking Progress
| Metric | What it tells you |
|---|---|
| Velocity | Average story points completed per Sprint. Used to forecast future capacity. Stabilizes after a few Sprints. |
| Burndown chart | Remaining work (points or tasks) plotted against time. Healthy: trends down toward zero by Sprint end. Flat = stalled. |
| Burnup chart | Shows completed work and total scope on one chart — makes scope creep visible. |
Velocity is a planning tool for the team, never a productivity metric for comparing teams or judging individuals.
Phase 5 — Sprint Closure
Two events close every Sprint, in this order.
Sprint Review — inspect the product
The Scrum Team demos the working Increment to stakeholders. Focus: what got done, what didn't, what's next. The PO and stakeholders may re-order the Product Backlog based on what they see. Working session, not polished presentation.
Only items meeting the Definition of Done are demoed. Incomplete work returns to the Product Backlog for re-prioritization.
Time-box: ~1h per week of Sprint.
Sprint Retrospective — inspect the process
The Scrum Team alone (no external stakeholders — psychological safety matters). Reflect on:
- What went well?
- What didn't?
- What will we change next Sprint?
Output: 1–3 concrete action items. This is the engine of continuous improvement; skipping it is the most common way teams stagnate.
Time-box: ~45 min per week of Sprint.
Then — repeat
The next Sprint Planning begins immediately. The cycle continues until the product is retired or the team disbands.
Definition of Done vs Acceptance Criteria
Two distinct concepts, often confused:
| Definition of Done | Acceptance Criteria | |
|---|---|---|
| Scope | Applies to every backlog item | Story-specific |
| Question | "Is any story finished to our quality bar?" | "Is this story correct?" |
| Owner | Scrum Team (or org standard) | PO drafts; team confirms |
| Example | coded, peer-reviewed, tested, documented, merged, deployed to staging | the form rejects emails without @ |
DoD is the team's quality contract. AC is the per-story spec.
Chronological Cheat Sheet
ONE-TIME / ONGOING (before and between Sprints)
Product vision & brainstorming
└─ Write user stories (As a… I want… so that…)
└─ Build & order the Product Backlog
└─ Refinement (ongoing)
└─ Estimate with story points / Planning Poker
EACH SPRINT (the repeating loop)
1. Sprint Planning → Sprint Goal + Sprint Backlog (Why / What / How)
2. Daily Scrum → 15-min Developer planning event, every day
3. Development work → build, track on board + burndown
4. Sprint Review → demo Increment to stakeholders (inspect product)
5. Sprint Retrospective → 1–3 action items for the team (inspect process)
6. ↺ back to step 1
Glossary
- Epic — A story too large for one Sprint; gets split during refinement.
- Spike — A time-boxed research task to reduce uncertainty before estimating.
- Velocity — Average story points completed per Sprint.
- Time-box — A fixed maximum duration for an activity.
- Increment — The usable output of a Sprint, meeting the Definition of Done.
- Servant-leader — Leadership by enabling and unblocking the team rather than directing it.
- WIP limit — Cap on items in progress at once (more central to Kanban than Scrum).
Scrum is intentionally lightweight: 3 accountabilities, 3 artifacts, 5 events. If something feels heavier than that, it's probably a team addition — not core Scrum.