Scrum is a lightweight framework for developing and sustaining complex products. It is intentionally incomplete — it defines boundaries within which teams develop their own practices. Created by Ken Schwaber and Jeff Sutherland.
Roles
| Role | Responsibility | Is NOT |
|---|---|---|
| Product Owner | Maximises value of the product; owns and orders the backlog; single point of accountability for “what” | A project manager or requirements clerk |
| Scrum Master | Coaches the team in Scrum; removes impediments; serves the organisation | A team lead, task assigner, or secretary |
| Developers | Self-organising professionals who deliver the Increment; own “how” | Interchangeable resources |
The PO decides what to build and why. Developers decide how. The SM ensures the framework is understood and enacted.
Events
All events are timeboxed. The Sprint itself is the container event.
| Event | Timebox (2-week sprint) | Purpose |
|---|---|---|
| Sprint | 2 weeks (1–4 weeks allowed) | Fixed-length iteration producing a Done Increment |
| Sprint Planning | 4 hours max | Define Sprint Goal; select and decompose backlog items |
| Daily Standup | 15 minutes | Inspect progress toward Sprint Goal; adapt the plan |
| Sprint Review | 2 hours max | Inspect the Increment with stakeholders; adapt the backlog |
| Sprint Retrospective | 1.5 hours max | Inspect the team’s process; commit to improvements |
Sprint Planning in Detail
Sprint planning answers three questions:
- Why is this Sprint valuable? — the PO proposes a Sprint Goal
- What can be Done this Sprint? — developers select items from the Product Backlog
- How will the chosen work get done? — developers decompose items into tasks (typically ≤ 1 day)
Capacity planning — account for holidays, on-call, and support duties. Don’t plan at 100% capacity; 70–80% is realistic.
Velocity is a planning tool, not a target. It tells you what the team has historically delivered. Using it as a performance metric destroys its usefulness.
Definition of Ready vs Definition of Done
- Ready: a backlog item is refined enough to pull into a sprint (acceptance criteria, sized, dependencies identified)
- Done: the Increment meets the team’s quality bar (tested, reviewed, deployable, documented if needed)
Ready gates the entry; Done gates the exit. Both should be explicit and agreed by the team.
Artefacts
Product Backlog
An ordered list of everything needed in the product. The PO is accountable for it. Items near the top are smaller and better defined; items further down are larger and vaguer.
Refinement (grooming) is an ongoing activity — not a ceremony. The team spends roughly 10% of sprint capacity on it.
Sprint Backlog
The set of Product Backlog items selected for the Sprint plus the plan for delivering them and the Sprint Goal. Owned entirely by the developers.
Increment
The sum of all Product Backlog items completed during the Sprint plus all prior increments. Each Increment must be usable and meet the Definition of Done.
Definition of Done
A shared checklist of quality criteria. Example:
- Code reviewed
- Unit tests passing
- Integration tests passing
- No known critical bugs
- Deployed to staging
- Documentation updated (if applicable)
If teams don’t have a strong DoD, “done” becomes subjective and technical debt accumulates invisibly.
User Stories
Not prescribed by Scrum but widely used. Format:
As a [user role], I want [goal] so that [benefit].
Good stories follow INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Acceptance criteria make stories concrete. Use Given/When/Then for clarity:
- Given I am logged in
- When I click “Export”
- Then a CSV downloads containing my data
Estimation
Common approaches:
| Method | How it works | Best for |
|---|---|---|
| Story Points (Fibonacci) | Relative sizing: 1, 2, 3, 5, 8, 13, 21 | Teams wanting velocity tracking |
| T-shirt Sizing | XS, S, M, L, XL | Quick roadmap-level estimation |
| NoEstimates | Slice work small enough that each item ≈ 1 day | Mature teams with consistent throughput |
Planning Poker is a useful technique for story-point estimation: each developer privately selects a value, all reveal simultaneously, then discuss outliers.
Common Pitfalls
Sprint Goal forgotten — without a clear goal, the sprint becomes a grab-bag of tickets. The goal gives focus and allows trade-offs within the sprint.
Retro actions not tracked — retros without follow-through breed cynicism. Track improvement items in the backlog and give them the same visibility as feature work.
PO absent or unavailable — if the PO can’t answer questions during the sprint, developers guess or block. The PO must be accessible.
SM acting as PM — the Scrum Master is not a project manager. They don’t assign work, chase deadlines, or report status upward.
Sprints as mini-waterfalls — analysis in week 1, dev in week 2, testing at the end. Each day should see items moving through to Done.
Overfilling sprints — teams commit to more than capacity allows, then carry work over. This erodes trust and predictability. Undercommit slightly and pull in extra work if there’s capacity.
Ignoring technical debt — every sprint should include some capacity for refactoring and paying down debt. If it’s never prioritised, velocity will decline over time.
Links
- The Scrum Guide (2020)
- Scrum.org
- Agile — the values underpinning Scrum
- Kanban — alternative flow-based approach