Deliver work in short, steady cycles: agile values, Scrum roles and events, Kanban flow, backlogs, sprints, retrospectives, metrics and tools.

Agile Delivery: Scrum & Kanban

## Why it matters

In Project Management Fundamentals you planned a project up front: scope, schedule, critical path. That works well when the requirements are clear and stable, like building a car park. In software and digital products they rarely are. Users only know what they want once they see something, technology changes, and the market moves. Agile is a response to that uncertainty: deliver something small, learn from it, adjust, repeat.

## Waterfall in one picture

A **waterfall** (or predictive, plan-driven) project runs through phases in order:

```text
Requirements -> Design -> Build -> Test -> Deploy
```

Each phase finishes before the next starts, and changes after sign-off go through change control. Its strengths are predictability and clear documentation. Its weakness is that users see working software only at the end, so a misunderstanding in month one is discovered in month nine, when it is most expensive to fix.

## The Agile Manifesto

In February 2001, seventeen software practitioners met in Snowbird, Utah, and wrote the **Manifesto for Agile Software Development**. It is short enough to read in a minute at [agilemanifesto.org](https://agilemanifesto.org/). Its four values:

> **Individuals and interactions** over processes and tools
> **Working software** over comprehensive documentation
> **Customer collaboration** over contract negotiation
> **Responding to change** over following a plan
>
> That is, while there is value in the items on the right, we value the items on the left more.

The last line matters. Agile does not say "no documentation" or "no plan". It says that when the two conflict, prefer the left-hand side.

## The twelve principles, grouped

The manifesto also lists twelve principles. Grouped by theme:

- **Deliver value early and often**: satisfy the customer through early and continuous delivery; deliver working software frequently, from every couple of weeks to every couple of months; working software is the primary measure of progress.
- **Welcome change**: changing requirements are welcome, even late in development.
- **Work together**: business people and developers work together daily; face-to-face conversation is the most effective way to share information; build projects around motivated individuals and trust them.
- **Sustainable pace**: teams should be able to keep a constant pace indefinitely.
- **Quality and simplicity**: continuous attention to technical excellence and good design; simplicity, the art of maximising the amount of work not done, is essential.
- **Self-organisation and reflection**: the best designs emerge from self-organising teams; at regular intervals the team reflects on how to become more effective and adjusts.

## A worked comparison

Our running example for this course: **Northside Sports Centre** wants an app so members can book courts and classes.

**Waterfall plan:** three months of requirements and design, five months of build, one month of testing, launch in month nine. The sponsor sees a working app for the first time in month eight.

**Agile plan:** two-week sprints. By the end of sprint 1 the team can show a member booking a badminton court on a test phone. By sprint 3 a small group of real members uses it for courts only. Their feedback (they mostly book on the bus, so it must work one-handed) changes the design of everything that follows. Classes and payments come later, in the order members value them.

The total budget may be similar. The difference is when you learn, and how much is wasted when you learn something surprising.

## When waterfall still fits

Agile is not always better. A plan-driven approach can suit work where:

- requirements are fixed by law or physics and unlikely to change,
- the work cannot be delivered in usable pieces (you cannot ship half a bridge),
- contracts require a fixed scope and price, or
- regulators require full documentation up front.

Many organisations use a **hybrid**: plan-driven for the overall budget, milestones and hardware, agile within delivery teams. PMI's guidance and the PMP exam now cover predictive, agile and hybrid approaches.

## Common mistakes

- **"Agile means no planning."** Agile teams plan constantly, just in smaller pieces and closer to the work.
- **"Agile means no documentation."** Teams write what is useful: acceptance criteria, decisions, how to run the system.
- **Renaming phases as sprints.** Two weeks of requirements followed by two weeks of design is still waterfall.
- **Adopting the ceremonies but not the values.** Daily stand-ups without trust or customer feedback do not make a team agile.

## Quick recap

- Waterfall runs phases in sequence; agile delivers small working increments and adapts.
- The manifesto's four values prefer people, working software, collaboration and responding to change, without discarding the alternatives.
- The twelve principles stress frequent delivery, welcoming change, collaboration, sustainable pace, quality and reflection.
- Waterfall or hybrid still fits fixed, non-incremental or heavily regulated work.


The four values and twelve principles of the Agile Manifesto, and when agile beats a waterfall plan and when it does not.

Agile values

What is the Agile Manifesto? | Google Project Management Certificate

Agile vs. Waterfall Project Management - Wrike

## Why it matters

**Scrum** is the most widely used agile framework. If you work on or with a software or product team, you will hear its words every day: sprint, product owner, backlog, stand-up, retro. Knowing exactly what each one means, and what it does not mean, lets you take part from day one and spot when a team's "Scrum" has drifted.

Scrum is defined in **The Scrum Guide** by its creators, Ken Schwaber and Jeff Sutherland. The current version (2020) is free and under 20 pages at [scrumguides.org](https://scrumguides.org/). Checked on 2026-10-23. This lesson follows it.

## The idea in one paragraph

Scrum is a lightweight framework for solving complex problems in short cycles called **sprints**, each one month or less (two weeks is common). In every sprint a small team turns the most valuable items from a backlog into a usable **increment**, shows it to stakeholders, and reflects on how to work better. Scrum rests on **empiricism**: transparency, inspection and adaptation. You make the work visible, check it often and change course based on what you see.

## Three accountabilities

A **Scrum Team** is small, typically 10 or fewer people, with no sub-teams or hierarchy. It has three accountabilities:

| Accountability | Owns | Northside Sports Centre example |
|---|---|---|
| **Product Owner** | Maximising the value of the product; the Product Backlog and its order | The centre's membership manager, who decides that court booking comes before class booking |
| **Scrum Master** | The team's effectiveness and how well Scrum is understood and used | A coach who removes blockers, facilitates events and helps the organisation work with the team |
| **Developers** | Creating a usable increment every sprint | The designers, programmers and testers building the app |

"Developers" means everyone doing the work, not only programmers. A Scrum Master is not a project manager handing out tasks, and the Product Owner is one person, not a committee, though they can take input from many stakeholders.

## Five events

| Event | Purpose | Timebox (one-month sprint) |
|---|---|---|
| **The Sprint** | The container for all the other events | One month or less |
| **Sprint Planning** | Decide why this sprint is valuable (Sprint Goal), what can be done and how | Up to 8 hours |
| **Daily Scrum** | Developers inspect progress towards the Sprint Goal and adjust the plan | 15 minutes |
| **Sprint Review** | Inspect the increment with stakeholders and adapt the Product Backlog | Up to 4 hours |
| **Sprint Retrospective** | Inspect how the team worked and plan improvements | Up to 3 hours |

For shorter sprints the events are usually shorter. A two-week sprint might have about four hours of planning, a 15-minute Daily Scrum each day, a two-hour review and a 90-minute retrospective.

Note what the Daily Scrum is *not*: a status report to a manager. The guide removed the "three questions" (what did I do yesterday, what will I do today, any blockers) as a requirement in 2020; teams can use any structure that focuses on the Sprint Goal.

## Three artifacts and their commitments

Each artifact has a **commitment** that gives it focus:

| Artifact | What it is | Commitment |
|---|---|---|
| **Product Backlog** | An ordered list of everything that might be needed in the product | **Product Goal**: the long-term objective |
| **Sprint Backlog** | The Sprint Goal, the items chosen for the sprint and the plan to deliver them | **Sprint Goal**: the single objective for the sprint |
| **Increment** | A usable step towards the Product Goal, added to all previous increments | **Definition of Done**: the quality standard every increment meets |

The **Definition of Done** is the team's shared checklist: for example "code reviewed, tests pass, accessible, deployed to the test environment, product owner has seen it". An item that does not meet it is not part of the increment and goes back to the Product Backlog.

## One sprint, end to end

```text
Day 1      Sprint Planning: goal "A member can book and cancel a court on their phone"
Days 1-10  Daily Scrum each morning; Developers build, test and integrate
           Product Backlog Refinement runs alongside (not an event, but ongoing)
Day 10     Sprint Review: demo to the centre manager and two members; backlog updated
Day 10     Sprint Retrospective: team agrees one improvement for next sprint
Day 11     Next sprint starts with Sprint Planning
```

## Common mistakes

- **The Scrum Master as boss** who assigns tasks. Developers decide how to do the work.
- **A proxy or committee Product Owner** with no authority to say no.
- **Skipping the retrospective** when busy, which removes the improvement loop.
- **Sprint Review as a one-way demo** with no stakeholder feedback and no change to the backlog.
- **Extending the sprint** to finish work. The timebox is fixed; unfinished work returns to the backlog.

## Quick recap

- Scrum delivers a usable increment every sprint of one month or less, based on transparency, inspection and adaptation.
- Three accountabilities: Product Owner, Scrum Master, Developers.
- Five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Three artifacts with commitments: Product Backlog (Product Goal), Sprint Backlog (Sprint Goal), Increment (Definition of Done).


Map Scrum's three accountabilities, five events and three artifacts, and how they fit into one sprint.

Scrum roles and events

Scrum Essentials in Under 10 Minutes

What are Scrum Roles, Events and Artifacts? | #pmi

Write down the stages your work really goes through (for example: To do, Doing, Waiting, Done) and make one column per stage.

Put every current item on a card in the right column, including things you have started and paused.

Count the items in each active column and write the number at the top.

Set a WIP limit for each active column, lower than the current count where it is overloaded.

Write two explicit policies, for example what must be true before a card can move to Done.

Use the board for at least three days. When a column is full, finish or unblock something before pulling new work.

Note how many items you finished and whether any item waited in one column for more than a day.

## Why it matters

Not all work fits neatly into two-week sprints. A support team handles requests as they arrive. An operations team mixes planned work with urgent fixes. A design team serves several product teams at once. **Kanban** gives these teams, and many Scrum teams too, a way to see their work, stop starting too many things at once and finish work faster and more predictably.

## Where it comes from

*Kanban* is Japanese for "signboard" or "visual card". The idea comes from the Toyota Production System in the mid-20th century, where cards signalled when to produce more parts, so nothing was made before it was needed. In the 2000s David J. Anderson and others adapted it for knowledge work. Today the core practices are described in free guides such as The Kanban Guide and Scrum.org's Kanban Guide for Scrum Teams, and in the Kanban Method taught by Kanban University.

## The core practices

The wording differs between guides, but the core practices are commonly summarised as:


1. **Visualise the work.** Put every item on a board with one column per stage of your workflow.
2. **Limit work in progress (WIP).** Set a maximum number of items allowed in each active column.
3. **Manage flow.** Watch how items move, find where they get stuck and fix the cause.
4. **Make policies explicit.** Write down the rules: what "done" means for each column, who can pull work, how urgent items are handled.
5. **Improve continuously** using feedback and data.

Kanban has no required roles, no sprints and no fixed events. You start with what you do now and improve it in small steps.

## A board with WIP limits

Northside Sports Centre's app team uses this board:

```text
| Backlog | Ready (5) | In progress (3) | Review (2) | Testing (2) | Done |
|---------|-----------|-----------------|------------|-------------|------|
| ...     | A  B  C   | D  E  F         | G  H       | I           | J  K |
|         | L         |                 |            |             |      |
```

The numbers in brackets are **WIP limits**. "In progress" already holds three items, so nobody may start a fourth. If a developer finishes item D, they **pull** the next item from Ready. Work is pulled when there is capacity, not pushed onto people.

## Why limiting WIP works

It feels backwards: surely starting more things gets more done? It does not, for three reasons.

- **Context switching**: every switch between tasks costs time to get back into the problem.
- **Queues hide**: with ten things "in progress", most of them are actually waiting.
- **Little's Law**: for a stable system, average cycle time = average WIP / average throughput.

A worked example. The team finishes about **6 items a week** (throughput). If they keep **18 items** in progress, the average item takes 18 / 6 = **3 weeks** from start to finish. If they cut WIP to **6 items**, with the same throughput, the average item takes 6 / 6 = **1 week**. Nobody worked faster. Items simply waited less.

## What a WIP limit makes you do

When a column hits its limit, the board is telling you something. Suppose Review (limit 2) is full because the only reviewer is on leave. Developers cannot start new work, so instead they **swarm**: help review, pair on testing, or fix whatever blocks the flow. This is the point. WIP limits turn a hidden bottleneck into a visible one and push the team to fix it.

## Setting the first limits

There is no perfect formula. A common starting point:

- Count how many people work in each stage and start with a limit near that number (or slightly less, to encourage pairing).
- Run for two or three weeks and watch: if items queue up before a column, look at that stage; if people are often idle, raise the limit a little.
- Change one limit at a time so you can see the effect.

## Kanban and Scrum together

Many teams use a Kanban board inside Scrum (sometimes called "Scrumban"): sprints, planning and retrospectives from Scrum, plus WIP limits and flow metrics from Kanban. Scrum.org's Kanban Guide for Scrum Teams describes exactly this.

| | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed-length sprints | Continuous flow |
| Roles | Product Owner, Scrum Master, Developers | None required |
| Limits work by | What fits in the sprint | WIP limits per column |
| Change during the cycle | Sprint Backlog can be renegotiated, Sprint Goal stays | New work can be pulled any time there is capacity |
| Key metrics | Sprint Goal met, velocity (optional) | Cycle time, throughput, WIP |

## Common mistakes

- **A board without WIP limits**: that is a task board, not Kanban.
- **Ignoring the limits** "just this once" until they mean nothing.
- **Too many columns**, so the board copies an org chart instead of the workflow.
- **No explicit policies**, so everyone has a different idea of when an item can move.

## Quick recap

- Kanban visualises work, limits WIP, manages flow, makes policies explicit and improves continuously.
- Work is pulled when there is capacity, not pushed.
- Lower WIP shortens cycle time without anyone working faster (Little's Law).
- Kanban can stand alone or run inside Scrum.

## Try it

Open the **Do** tab and build a Kanban board with WIP limits for your own work.


Visualise work on a Kanban board, set work-in-progress limits and manage flow instead of timeboxes.

Kanban and flow

What is Kanban? | Explained for Beginners in 6 Minutes

A Short Introduction to Kanban WIP Limits | Businessmap

The agile values and principles, how Scrum's roles, events and artifacts fit together, and how Kanban manages flow.