The Scrum Framework, Kanban, and Scaling Agile
Scrum: The Dominant Agile Framework
Scrum is a management framework, not a technical one. Unlike XP (which tells you how to write code), Scrum tells you how to organise the work. It is the most widely adopted Agile framework today.
Scrum is founded on empiricism: knowledge comes from experience, and decisions are made based on what is actually observed — not what was planned six months ago.
The Three Pillars
| Pillar | Meaning |
|---|---|
| Transparency | The process, the work, and the blockers must be visible to everyone involved. Hidden problems cannot be solved. |
| Inspection | Artifacts (Product Backlog, Sprint Backlog, Increment) must be frequently inspected to detect undesirable divergence from the goal. |
| Adaptation | If inspection reveals that a process or product is deviating outside acceptable limits, it must be adjusted as soon as possible — not deferred to the next quarterly review. |
Scrum Artifacts
- Product Backlog: the master, ever-evolving to-do list. Replaces the 500-page Waterfall spec. Items near the top are small, highly detailed, and ready for Sprint selection. Items near the bottom are large, vague ideas that will be refined later. The Product Owner is the sole owner.
- User Story format: a lightweight way to express a backlog item. Template: “As a [user/persona], I want [action/feature], so that [value/reason].” Example: “As a student, I want to filter my timetable by term, so that I only see current lectures.”
- Acceptance Criteria: specific, testable conditions that must be met for the story to be considered Done. They define the boundaries of the story’s scope.
- Definition of Done (DoD): a universal team checklist, shared across all stories. Typical items: code reviewed by at least one peer, all automated tests pass, documentation updated, deployed to a staging environment and smoke-tested. If a story does not meet the DoD, it is not done — no exceptions, no “mostly done,” no “done except for testing.”
- Sprint Backlog: the set of Product Backlog items selected for this Sprint, plus the team’s plan for delivering them.
- Increment: the sum of all completed Product Backlog items during a Sprint. It must be potentially releasable — meaning it meets the DoD and could, if the Product Owner decides, be shipped to real users at the end of the Sprint.
Scrum Events (Ceremonies)
| Event | Duration | Purpose |
|---|---|---|
| Sprint | Fixed timebox, usually 2 weeks | Produce a Done, usable, potentially releasable Increment. During the Sprint, no changes are made that would endanger the Sprint Goal; urgent new work goes into the next Sprint’s backlog. |
| Sprint Planning | Max 8 hours for a 1-month Sprint | Defines the Sprint Goal, selects backlog items, and decomposes them into technical tasks the Developers commit to. |
| Daily Scrum (Standup) | 15 minutes, time-boxed | Developers synchronise: What did I do yesterday? What will I do today? Any blockers? It is not a status report for management — it is a developer coordination meeting. |
| Sprint Review | Max 4 hours | At Sprint end, the team presents the Increment to stakeholders. A working session — not a formal slide-deck presentation. Feedback updates the Product Backlog for future Sprints. |
| Sprint Retrospective | Max 3 hours | After the Review, before the next Planning. The team inspects its own process: what went well, what went wrong, what should we change? Produces at least one concrete improvement action. |
Scrum Roles
| Role | Responsibility |
|---|---|
| Scrum Master | Servant-leader. Facilitates Scrum events, removes blockers (impediments), protects the team from external interruptions and scope injection during a Sprint. Does not assign tasks or dictate technical decisions. Coaches the team and the organisation in Scrum. |
| Product Owner (PO) | Represents the business and the customer. Sole owner of the Product Backlog — determines priority by business value. The single person the Developers go to for requirements clarification. |
| Developers | Cross-functional, self-organising. Nobody — not the Scrum Master, not the PO — tells them how to turn backlog items into a Done Increment. They own the “how.” |
Estimation: Story Points
Humans are terrible at estimating absolute time (“this will take 3 days”) but much better at relative sizing (“this story is about twice as complex as that one”).
Story Points are an abstract measure of complexity, effort, and risk — not time. Common scales: Fibonacci (1, 2, 3, 5, 8, 13) or T-shirt sizes (S, M, L, XL).
Planning Poker: the team votes simultaneously using numbered cards. Large discrepancies (e.g. Alice votes 2, Bob votes 8) trigger a brief discussion: Bob explains what complexity Alice may have missed, or Alice explains a simpler approach Bob hadn’t considered. The team re-votes. This surfaces hidden complexity without anchoring on the first number spoken.
”Scrum-but”: Fake Agile
“We do Scrum, but our Sprints are 6 weeks.” “Management injects urgent tasks into the Sprint at will.” “We skip Retrospectives because we are too busy.” The result is Waterfall disguised with Agile vocabulary — a team that has adopted the terminology without the discipline, leading to burnout and failed projects. The Retrospective is often the first ceremony abandoned under pressure, but it is arguably the most important: it is the mechanism by which the process itself improves.
Kanban
Kanban originates from the Toyota Production System (lean manufacturing). It visualises work on a board with columns: To Do, In Progress, In Review, Done. Unlike Scrum, there are no time-boxed Sprints — items are pulled continuously as capacity frees up.
WIP (Work-In-Progress) Limits: each column has a strict limit (e.g. “at most 3 items in ‘In Progress’ at once”). If the limit is reached, no one may pull new work — they must instead help clear the column’s bottleneck. This optimises for flow (throughput) rather than batching features into Sprints.
When to use Kanban over Scrum: operations and maintenance teams that handle a continuous stream of incoming tickets, where the work arrives unpredictably and varies wildly in size — triaging security alerts, responding to customer-reported bugs, or maintaining a legacy system with no new feature development.
Scaling Agile
Scrum works for a single team of 5–9 people. To coordinate work across tens or hundreds of teams:
- SAFe (Scaled Agile Framework): highly structured, hierarchical. Popular in large enterprises and government. Critics call it “Waterfall in Agile disguise” because of its top-down planning layers.
- LeSS (Large-Scale Scrum): keeps Scrum principles while scaling to multiple teams sharing a single Product Backlog and one Product Owner.
- Spotify Model: Guilds (communities of interest across Squads), Tribes (collections of Squads in a business area), Squads (autonomous, cross-functional mini-startups). Spotify themselves no longer strictly follow this model — it evolved and they evolved with it, which is itself a lesson in process adaptation.
Expected Learning
- Name the three pillars of Scrum and explain how each enables empiricism.
- List the three Scrum artifacts and describe their contents and purpose.
- Name the five Scrum events with their maximum durations and purposes.
- Distinguish the three Scrum roles.
- Explain what Story Points measure and describe how Planning Poker works.
- Contrast Kanban with Scrum in terms of Sprints, WIP limits, and appropriate use cases.
- Recognise “Scrum-but” anti-patterns and explain why they undermine the framework.
- Name at least one scaling framework and describe the coordination problem it addresses.
Past Paper Questions
Example Sheet 1, Question 7 tests your ability to identify which Scrum principles are violated by a dysfunctional team (standups lasting 2 hours, no working software at Sprint end) and to suggest how the Retrospective — the specific Scrum ceremony — could be used to fix these problems. Example Sheet 1, Question 8 tests the “customer collaboration over contract negotiation” value in the context of a government project.