Most software, product and IT teams now deliver in short cycles using Scrum, Kanban or a mix of both. This intermediate course explains how that works in practice, following one small team that builds a booking app for a community sports centre. You will learn the agile values and how they differ from a plan-everything-first waterfall approach, how Scrum's roles, events and artifacts fit together, and how Kanban uses work-in-progress limits to keep work flowing; then refine and estimate a backlog, plan a sprint around a goal and run a review and a retrospective; and finally read burndown charts and cycle-time data, set up a board in a free tool and compare the main certifications (Scrum.org PSM, Scrum Alliance CSM, PMI-ACP and SAFe). Each lesson has a short reading, curated videos and a practical task. It builds on Project Management Fundamentals; the one code exercise is fill-in-the-blank and needs no programming experience.

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.

Agile Thinking

Split it into at least six vertical stories using at least three different splitting patterns from the reading. Label the pattern you used for each.

Write two or three acceptance criteria for the top three stories.

Make planning poker cards with 1, 2, 3, 5, 8, 13 and 20 (paper is fine).

Estimate every story with planning poker. If you are alone, estimate twice a day apart without looking at your first answers and compare.

For any story estimated above 13, split it again and re-estimate the pieces.

Put the stories in order of value and mark which ones meet your Definition of Ready.

## Why it matters

A sprint can only go well if the items going into it are understood, small enough to finish and roughly sized. Getting them there is **Product Backlog refinement**: the ongoing work of breaking items down, adding detail and estimates, and reordering. The Scrum Guide calls it an ongoing activity rather than an event; many teams hold a regular one-hour session each week. Analysts and designers often lead the preparation.

## What a ready backlog looks like

A healthy Product Backlog is shaped like an iceberg, sometimes described with the acronym **DEEP**:

- **Detailed appropriately**: items near the top are small and clear; items further down can be rough.
- **Estimated**: the top items have sizes.
- **Emergent**: it changes as the team learns.
- **Prioritised** (ordered): the most valuable work is at the top.

Many teams agree a **Definition of Ready**: for example, the item has a clear user story, acceptance criteria, no unresolved dependencies, and the team has sized it. Use it as a guide, not a gate that stops all conversation.

## Splitting stories

Big items (epics) must be split until each piece fits comfortably in a sprint, ideally several per sprint. The key is to split **vertically**: each piece is a thin slice through every layer (screen, logic, data) that a user can actually use. Splitting horizontally ("build the database", "build the screens") produces pieces that deliver no value alone.

Useful splitting patterns, using Northside Sports Centre's epic *"Members can book activities on the app"*:

| Pattern | Split into |
|---|---|
| Workflow steps | Browse free slots; book a slot; cancel a booking |
| Business rules | Book any free court; then add "members may hold at most 3 future bookings" |
| Data types | Courts first; classes later (classes have capacity and instructors) |
| Happy path first | Book with no problems; then handle "slot taken while you were booking" |
| Interface | Phone app first; desktop later |
| Simple then complex | Pay at the desk; then pay in the app |

After splitting, check each story against INVEST (independent, negotiable, valuable, estimable, small, testable), covered in Business & Systems Analysis.

## Estimating with story points

Teams usually estimate in **story points**: a relative measure of effort, complexity and uncertainty together. A 2-point story is roughly twice the work of a 1-point story; points are not hours. Relative sizing works because people are much better at comparing ("this is about twice that") than at predicting absolute time.

Most teams use a modified **Fibonacci scale**: 1, 2, 3, 5, 8, 13, 20. The growing gaps reflect growing uncertainty. Anything above 13 is usually a sign the item should be split.

### Planning poker

1. The Product Owner reads a story and answers questions.
2. Each developer privately picks a card with their estimate.
3. Everyone reveals at the same time, so nobody anchors on the loudest voice.
4. If estimates differ widely, the highest and lowest explain their reasoning.
5. Re-vote until the team converges, usually in two or three rounds.

The discussion is the real value. If one person says 2 and another says 13 for "Cancel a booking", one of them knows something: perhaps a refund rule, perhaps an existing feature that makes it easy. Either way the team learns before building.

### A worked refinement

```text
Story                                         Votes         Result
Browse free courts for a day                  3 3 5 3       3
Book a free court                             5 5 5 8       5
Cancel a booking (refund rule unclear)        2 13 5 8      -> discuss: full refund up to 24h before
                                              5 5 5 5       5
Limit of 3 future bookings per member         2 2 3 2       2
Book a class (capacity, waiting list)         13 20 20 13   -> too big, split into "book class" and "waiting list"
```

## Other estimation options

- **T-shirt sizes** (S, M, L, XL) for rough sizing far down the backlog.
- **Affinity estimation**: lay all cards on a table and group them by relative size; fast for many items.
- **No estimates**: some Kanban teams skip sizing and simply split everything to roughly similar small sizes, then forecast from throughput.

## Common mistakes

- **Converting points to hours** or comparing points between teams. Points only mean something within one team.
- **Horizontal splits** that deliver nothing usable on their own.
- **Refining too far ahead**: detailed stories for work six months away go stale.
- **The Product Owner estimating.** The people doing the work estimate it.

## Quick recap

- Refinement keeps the top of the backlog small, clear, estimated and ordered.
- Split vertically using workflow, rules, data, happy path or interface patterns.
- Story points are relative; use a Fibonacci-like scale and split anything very large.
- Planning poker reveals hidden knowledge through discussion of different estimates.

## Try it

Open the **Do** tab and refine a small backlog with planning poker.


Split large backlog items into small stories and estimate them with story points and planning poker.

Backlog refinement

Facilitating Product Backlog Refinement

What Are Story Points in Agile? (Agile Estimation Explained)

Choose a sprint length (one or two weeks) and list an imaginary team of three to six people with any leave or other duties.

Calculate available capacity in person-days, subtracting leave, events and other duties, and show your working.

Invent velocities for the last three sprints that match that capacity and calculate the average.

Write a Sprint Goal as one outcome sentence. Check that it is not just a list of items.

Select backlog items that support the goal and total their points, staying at or slightly below the average velocity.

Break the two largest items into tasks of a day or less.

Write down which item you would drop first if the sprint runs into trouble, while still meeting the goal.

## Why it matters

Sprint Planning sets up everything that follows. A team that leaves planning with a clear goal and a realistic amount of work can make sensible trade-offs all sprint. A team that leaves with a long list of unrelated tickets and no goal will be busy, but nobody can say what the sprint was for, and the review becomes a list of half-finished items.

## The three questions

The Scrum Guide frames Sprint Planning around three topics:

1. **Why is this sprint valuable?** The Product Owner proposes how the product could increase its value, and the whole Scrum Team agrees a **Sprint Goal**.
2. **What can be done this sprint?** The Developers select items from the Product Backlog that support the goal, based on their capacity and past performance.
3. **How will the chosen work get done?** The Developers plan the work, often by breaking items into tasks of a day or less.

The Sprint Goal, the selected items and the plan together form the **Sprint Backlog**.

## Writing a good Sprint Goal

A Sprint Goal is **one objective** that gives the sprint focus and coherence. It describes an outcome, not a list of tickets.

| Weak goal | Why it is weak | Better goal |
|---|---|---|
| "Finish tickets 41, 42, 45, 48 and 50" | A list, not an objective | "A member can book and cancel a court on their phone" |
| "Work on payments" | No end point | "Members can pay for a court booking by card in the app, in the test environment" |
| "Do as much as possible" | No focus at all | "Find out whether members will use reminders, by shipping one reminder to 50 testers" |

A good goal lets the team make decisions mid-sprint. If an item turns out larger than expected, the Developers and Product Owner can drop or simplify **items** while still meeting the **goal**. The Scrum Guide says the Sprint Backlog can be renegotiated during the sprint, but the Sprint Goal does not change.

## Working out capacity

Before choosing items, the team works out how much time it really has. A worked example for Northside's two-week (10 working day) sprint:

```text
Developers: 5 people x 10 days                    = 50 person-days
Minus planned leave: Priya 2 days, Sam 1 day       = -3
Minus Scrum events and refinement (about 10%)      = -5
Minus support rota (one person, 1 day per week)    = -2
Available capacity                                 = 40 person-days
Last 3 sprints with similar capacity: 21, 24, 23 story points completed
Average velocity                                   = (21 + 24 + 23) / 3 = about 23 points
This sprint has about the same capacity, so plan for about 22-23 points.
```

Velocity (the points completed per sprint) is a **forecasting aid for the team**, not a target. Plan near your recent average, not your best-ever sprint.

## Choosing the items

With the goal "A member can book and cancel a court on their phone" and about 23 points:

```text
Browse free courts for a day              3   supports goal
Book a free court                         5   supports goal
Cancel a booking (24h refund rule)        5   supports goal
Booking confirmation screen               3   supports goal
Limit of 3 future bookings per member     2   supports goal
Fix: login fails on older Android phones  3   needed: members cannot book if they cannot log in
                                         ---
                                          21 points  (2 points of slack for surprises)
```

The team leaves "Book a class" (13 points) in the Product Backlog. It is valuable, but it does not serve this sprint's goal and would overload the sprint.

## Making the plan

For each item, the Developers sketch the work: design the screen, build the API call, write tests, accessibility check, update help text. Tasks of a day or less make progress visible at the Daily Scrum. They do not need to plan every task on day one; enough for the first few days is fine, and the plan grows as they learn.

The timebox is up to eight hours for a one-month sprint; for two weeks, about half that is common. A focused team with a well-refined backlog often needs much less.

## Common mistakes

- **No Sprint Goal**, or a goal that is just the list of items.
- **Overcommitting** by planning to the best-ever velocity or ignoring leave.
- **The Product Owner choosing the amount of work.** The Developers decide how much they can take on.
- **Planning poorly refined items**, so the first days of the sprint go on working out what the items mean.
- **Treating velocity as a performance target**, which leads to inflated estimates.

## Quick recap

- Sprint Planning answers why (Sprint Goal), what (items) and how (the plan).
- A good Sprint Goal is one outcome that guides trade-offs during the sprint.
- Work out real capacity, then plan near recent average velocity, leaving some slack.
- Choose items that serve the goal; leave the rest in the backlog.

## Try it

Open the **Do** tab and plan a sprint with a goal and a capacity calculation.


Plan a sprint around a single Sprint Goal, choose work that fits the team's capacity and make a first plan.

Sprint planning and goals

What is Sprint Planning in Scrum?

The Sprint Goal: What It Is and How It Can Help You

Choose a format (Start/Stop/Continue, 4Ls or Sailboat) and prepare the board.

Set the stage: state the goal of the retro and read a short version of the Prime Directive.

Give everyone five minutes of silent writing, one idea per note.

Group similar notes and let each person place three dot votes on the groups that matter most.

For the top group, ask "why?" until you find a cause you can act on.

Agree one action with an owner, a way to check it and a date to review it.

Close by asking everyone to rate the retro from 1 to 5 and say one thing to change next time.

## Why it matters

The last two events of a sprint are where Scrum's learning happens. The **Sprint Review** inspects the *product*: did we build the right thing, and what should we do next? The **Sprint Retrospective** inspects the *team*: how did we work, and what will we change? Skip them, or run them as box-ticking rituals, and a team can repeat the same mistakes for months.

## The Sprint Review

The Sprint Review is a **working session** with stakeholders, not a presentation. The Scrum Team shows what was done, stakeholders react, and together they decide what to do next. Its main output is an **updated Product Backlog**.

A practical agenda for a one-hour review of a two-week sprint at Northside Sports Centre:

```text
5 min   Product Owner: the Sprint Goal and whether it was met
20 min  Developers show the working increment on a real phone
        (a member books and cancels a court; the 3-booking limit kicks in)
15 min  Stakeholders try it and give feedback
        (front-desk staff: "we need to see app bookings on our screen too")
10 min  What changed in the world: usage numbers, a competitor's new app, budget
10 min  Product Owner updates the backlog order live; agree likely next steps
```

Tips:

- **Show working software**, not slides. If it is not done (by the Definition of Done), do not demo it.
- **Invite the right people**: real users, the sponsor, support staff.
- **Ask questions** that invite reactions: "What would stop you using this?" beats "Any questions?"
- **Record decisions** as backlog changes, not just meeting notes.

## The Sprint Retrospective

The retrospective is for the Scrum Team only, so people can speak openly. The Scrum Guide says the team inspects how the last sprint went "with regards to individuals, interactions, processes, tools, and their Definition of Done", identifies the most helpful changes and can add them to the next Sprint Backlog.

A widely used five-stage structure (from Esther Derby and Diana Larsen's book *Agile Retrospectives*):

1. **Set the stage**: welcome, the goal of the retro, and a quick check-in so everyone speaks early.
2. **Gather data**: what happened? Facts, events, feelings.
3. **Generate insights**: why did it happen? Look for patterns and causes.
4. **Decide what to do**: choose one to three concrete actions with owners.
5. **Close**: appreciate each other and check whether the retro itself was useful.

### Popular formats for gathering data

| Format | Columns or prompts |
|---|---|
| Start, Stop, Continue | What should we start doing, stop doing, keep doing? |
| Went well / To improve / Ideas | Simple and quick |
| 4Ls | Liked, Learned, Lacked, Longed for |
| Sailboat | Wind (helps), anchors (holds us back), rocks (risks), island (goal) |
| Timeline | Plot events and the team's mood across the sprint |

Changing the format every few sprints keeps people engaged.

### A worked retro outcome

Northside's team used Start, Stop, Continue. Three people wrote that stories arrived in the sprint with unclear refund rules. Digging in (insight): the Product Owner had no time with the finance team before refinement. Action:

```text
Action:   Before refinement, the PO checks any story touching money with finance.
Owner:    Product Owner
Measure:  No story in next sprint is blocked waiting for a finance decision.
Review:   At the start of the next retro.
```

One specific action with an owner and a way to check it is worth more than ten vague resolutions like "communicate better".

## Facilitation basics

- **Psychological safety first.** Many teams read out Norman Kerth's Prime Directive at the start: everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation.
- **Everyone writes before anyone talks** (silent brainstorming on sticky notes), so quiet people are heard.
- **Group and vote** (dot voting) to focus on what matters most.
- **Focus on the system, not individuals.** "Our review process lets big changes wait three days" rather than "Sam is slow at reviews".
- **Start the next retro by checking last time's actions.**

## Common mistakes

- **Review as a status meeting** with slides and no feedback.
- **Demoing unfinished work**, which hides the real state of the product.
- **Retros with no actions**, or the same actions every time.
- **Managers in the retro**, which makes people guarded.
- **Blame.** It shuts down honest discussion immediately.

## Quick recap

- The Sprint Review inspects the increment with stakeholders and updates the Product Backlog.
- The retrospective inspects how the team works and ends with a few concrete actions.
- Use a structure (set the stage, gather data, generate insights, decide, close) and vary formats.
- One owned, measurable action beats many vague ones; check it next time.

## Try it

Open the **Do** tab and facilitate a short retrospective.


Run a Sprint Review that changes the backlog, and facilitate a retrospective that ends in one real improvement.

Reviews and retrospectives

How to Facilitate the Sprint Retrospective

How to Facilitate the Sprint Review

Refine and estimate the backlog, plan a sprint around a goal, and close it with a review and a retrospective.

Running Iterations

## Why it matters

Stakeholders always ask two questions: "Are we on track?" and "When will it be done?" Agile teams answer with simple measures drawn from their own history rather than guesses. Read well, these measures help a team spot trouble early and give honest forecasts. Read badly, or turned into targets, they mislead everyone.

## Velocity

**Velocity** is the number of story points a Scrum team completes (to the Definition of Done) per sprint. Partly finished items count zero.

```text
Sprint      1    2    3    4    5
Completed  18   23   21   24   23   average of last 3 = (21 + 24 + 23) / 3 = about 22.7
```

Uses:

- **Sprint Planning**: a rough guide to how much to take on.
- **Release forecasting**: 90 points left in the backlog / about 22 points per sprint = about 4 sprints. Give a range (for example 4 to 5 sprints), not a single date.

Limits: velocity is specific to one team and its own estimating, so never compare teams by velocity. If you make it a target, estimates quietly inflate and the number stops meaning anything. This is Goodhart's law: when a measure becomes a target, it ceases to be a good measure.

## Burndown charts

A **sprint burndown** plots the work remaining (points or tasks) against the days of the sprint. A straight **ideal line** runs from the total at the start to zero on the last day.

Northside's 10-day sprint with 22 points:

```text
Day        0   1   2   3   4   5   6   7   8   9  10
Ideal     22  20  18  15  13  11   9   7   4   2   0   (rounded)
Actual    22  22  20  20  19  17  14  11   8   5   2
```

How to read it:

- **Above the ideal line**: work remains that "should" be done by now. On day 5 the team has 17 points left against an ideal of 11: behind.
- **Flat sections** (days 0 to 1, 2 to 3): nothing finished. Often items are in progress but none is done yet, which is normal early on but a warning if it lasts.
- **Steady steps down later**: work is flowing.
- **Ending above zero** (2 points left on day 10): an item will not be done and returns to the backlog.
- **Line going up**: work was added during the sprint.

The useful question is never "why are you above the line?" but "what is blocking us, and does our Sprint Goal still look achievable?"

### Burnup charts

A **burnup** chart shows two lines: total scope and work completed, both rising. Its advantage is that **scope changes are visible**. On a burndown, adding 10 points and finishing 10 points look like no progress; on a burnup you see the scope line jump and the done line climb. Burnups are popular for release tracking.

## Flow metrics: cycle time, lead time, throughput

Kanban teams (and many Scrum teams) use flow metrics:

- **Cycle time**: time from when work **starts** on an item to when it is **done**.
- **Lead time**: time from when the item is **requested** (enters the backlog) to done. The customer feels lead time.
- **Throughput**: items finished per period (per week, per sprint).
- **WIP**: items started but not finished.

Definitions vary between teams and tools; agree exactly which board columns mark "start" and "done".

### Reading cycle-time data

Here are ten finished items, with the day work started and the day each was done:

```text
Item   A  B  C  D   E  F  G  H   I   J
Start  1  1  2  3   4  5  6  7   8   9
Done   3  6  4  10  7  8  9  15  11  12
Cycle  2  5  2  7   3  3  3  8   3   3      average = 39 / 10 = 3.9 days
```

Sorted: 2, 2, 3, 3, 3, 3, 3, 5, 7, 8. The **average** is 3.9 days, but averages hide the long tail. A better forecast for a customer is a **percentile**: "85% of our items finish within **7 days**" (the 9th of 10 sorted values). That is a promise you can usually keep. A **cycle-time scatterplot** (one dot per item, done date on the x-axis, cycle time on the y-axis) shows the same data visually; dots far above the rest, like H at 8 days, are worth discussing in a retrospective.

## Using metrics well

- **Use them for the team's own learning and forecasting**, not to rank people or teams.
- **Look at trends**, not single values.
- **Combine with conversation**: a chart tells you where to ask, not what the answer is.
- **Forecast in ranges** with percentiles or several sprints of velocity.

## Common mistakes

- **Velocity as a performance target**, causing estimate inflation.
- **Comparing velocity across teams.**
- **Counting partly done work** in velocity.
- **Reporting only averages** for cycle time and making promises the long tail breaks.

## Quick recap

- Velocity is completed points per sprint; use it to plan and forecast within one team.
- Burndowns show remaining work against an ideal line; burnups also show scope changes.
- Cycle time runs from start to done, lead time from request to done; throughput counts items finished.
- Forecast with percentiles and ranges, and never turn the measures into targets.

## Try it

Open the **Do** tab. The program already calculates velocity, a burndown check and cycle-time statistics for Northside's data, except for one line. No programming experience needed.


Read velocity, burndown and burnup charts and cycle-time data, and use them to forecast without turning them into targets.

Velocity, burndown, cycle time

What are a Burndown Chart, a Burnup Chart, and Velocity?

Kanban Metrics (Lead Time, Cycle Time, Cumulative Flow Diagram)

Sign up for a free plan (or use an existing free account) and create a project or board using a Scrum or Kanban template.

Set up a workflow of five to seven statuses and write a one-line entry rule for each.

Make the board columns match the statuses and add WIP limits to the active columns (or write them in the column names if the tool has no WIP limit feature).

Create at least two epics and six stories with acceptance criteria in the description, linked to their epics.

Add story points or sizes and order the backlog.

Start a sprint with a written Sprint Goal (Scrum) or pull the top items into progress (Kanban), and move at least two items through to Done.

Open one built-in report (burndown, velocity, cumulative flow or control chart) and write one sentence on what it shows.

When you finish practising, archive or delete the practice project if you do not plan to keep it.

## Why it matters

Agile teams can run on sticky notes, and many great teams start that way. But once a team is distributed, works with other teams or needs history and reports, it moves to a tool. **Jira**, made by Atlassian, is the most common in software companies; others include Azure Boards, Linear, Trello, GitHub Projects, Asana and monday.com. Analysts, designers and project managers are often the people who set up and maintain the board, so knowing how to configure one well is a practical, hireable skill.

## The concepts every tool shares

Whatever the tool, you will meet the same ideas, though the names vary:

| Concept | Jira name | What it is |
|---|---|---|
| Work item | Issue (work item in newer versions) | A card: story, task, bug, epic |
| Item types | Issue types | Epic, Story, Task, Bug, Sub-task |
| Workflow | Workflow | The statuses an item passes through and the allowed moves |
| Board | Board | Columns mapped to workflow statuses |
| Backlog | Backlog | The ordered list of items not yet in a sprint |
| Sprint | Sprint | A timebox with selected items (Scrum boards) |
| Fields | Fields | Story points, assignee, priority, labels, due date |
| Filters | JQL filters | Saved searches that decide what a board shows |

## Scrum board or Kanban board?

Most tools offer both templates:

- A **Scrum board** has a backlog view, sprints you start and complete, and sprint reports such as burndown and velocity.
- A **Kanban board** shows continuous flow with WIP limits per column and reports such as the cumulative flow diagram and cycle-time (control) charts.

Pick the one that matches how the team works, not the one with more features.

## Designing the workflow

The workflow is the most important decision and the most commonly overcomplicated one. Start from how work really moves, as you did when building a Kanban board by hand:

```text
To Do  ->  In Progress  ->  In Review  ->  Testing  ->  Done
```

Guidelines:

- **Keep it short.** Five to seven statuses is plenty. Every extra status is a place for work to wait.
- **Each status should mean a real state**, with a clear entry rule: "In Review = pull request opened".
- **Show waiting explicitly** if it matters ("Waiting for customer"), so it is not mistaken for active work.
- **Map statuses to columns** and set **WIP limits** on the active columns.
- **Make "Done" match the Definition of Done.**

## Worked setup: Northside Sports Centre

The team sets up a free Jira Cloud site (the free plan has a user limit; check current terms on Atlassian's site) with a Scrum template:

1. **Create the project** from the Scrum template, key `NSC`, so items are numbered NSC-1, NSC-2 and so on.
2. **Issue types**: keep Epic, Story, Bug and Task; turn off anything the team will not use.
3. **Workflow**: To Do, In Progress, In Review, Testing, Done.
4. **Board columns** match the statuses; WIP limits of 4 for In Progress and 2 each for In Review and Testing.
5. **Epics**: "Court booking", "Class booking", "Payments".
6. **Backlog**: enter the refined stories with story points and acceptance criteria in the description, link each to its epic and order them.
7. **Start sprint 1** with the Sprint Goal written in the sprint's goal field.
8. **Quick filters** for "Bugs only" and "Assigned to me".

## Writing good items in a tool

- **Title**: short and specific, written from the user's view: "Member cancels a court booking".
- **Description**: the user story, acceptance criteria (Given/When/Then), links to designs.
- **One item, one outcome**: do not bury three changes in one ticket.
- **Link related items** (blocks / is blocked by) so dependencies show up.
- **Comment, do not overwrite**, so the history of decisions stays visible.

## Reports to look at

- **Sprint report / burndown**: progress within a sprint.
- **Velocity chart**: completed points over recent sprints.
- **Cumulative flow diagram**: bands for each status over time; a widening band shows a bottleneck.
- **Control chart (cycle time)**: how long items take, with outliers.

These are the metrics from the previous lesson, drawn for you, if the workflow and data are clean.

## Common mistakes

- **Too many statuses and mandatory fields**, so people avoid updating the tool.
- **The board does not match reality**: work happens in chat and the board is updated on Friday.
- **Using the tool to monitor individuals** rather than the flow of work.
- **Copying another team's configuration** without asking whether it fits.
- **Forgetting to clean up**: stale items at the bottom of the backlog nobody will ever do. Archive them.

## Quick recap

- All agile tools share items, types, workflows, boards, backlogs, sprints, fields and filters.
- Choose a Scrum or Kanban board to match how the team works.
- Keep the workflow short and real, with WIP limits and a Done that matches the Definition of Done.
- Clean data gives you useful reports; a cluttered tool gets ignored.

## Try it

Open the **Do** tab and set up a board in a free tool.


Set up a Scrum or Kanban board with a workflow, issue types, WIP limits and a backlog in a free tool.

Jira and boards

Jira Tutorial for Beginners | Atlassian Answered

Jira Tutorial for Beginners — Learn Jira in 20 Minutes

## Why it matters

Scrum and Kanban were designed for a single small team. Real products are often built by many teams at once: a bank's mobile app might involve ten teams, a shared platform team and a security team. Scaling frameworks try to keep those teams aligned without losing agility. You will also see agile certifications in almost every IT project manager, scrum master and analyst job advert, and it helps to know what each one actually tests.

## Why scaling is hard

When several teams work on one product, new problems appear:

- **Dependencies**: team A cannot finish until team B changes an API.
- **Integration**: each team's work must combine into one working product.
- **Priorities**: whose backlog wins when two teams need the same people?
- **Alignment**: everyone needs the same picture of the product goal.

The best first step is usually to **reduce** the need for coordination (organise teams around features or customer journeys so each can deliver end to end) before adding coordination layers.

## Common approaches

| Approach | In one line | Typical size |
|---|---|---|
| **Scrum of Scrums** | A representative from each team meets regularly to sort out cross-team dependencies | 2 to 10 teams |
| **Nexus** (Scrum.org) | 3 to 9 Scrum teams share one Product Backlog and one Product Owner, with a Nexus Integration Team | 3 to 9 teams |
| **LeSS** (Large-Scale Scrum) | One Product Owner and one backlog for many teams, keeping Scrum as simple as possible | 2 to 8 teams (LeSS Huge for more) |
| **SAFe** (Scaled Agile Framework) | A detailed framework with roles, events and artifacts at team, program (Agile Release Train) and portfolio levels | 50 to 125 people per release train; many trains |
| **Disciplined Agile** (now part of PMI) | A toolkit for choosing your own way of working rather than one framework | Any |

### SAFe in a little more detail

SAFe, from Scaled Agile, Inc., is the most widely adopted scaling framework in large enterprises. Its core idea is the **Agile Release Train (ART)**: a long-lived team of agile teams (typically 50 to 125 people) that plans together in a **PI Planning** event every **Planning Interval** (PI; called a Program Increment before SAFe 6.0; usually 8 to 12 weeks), then delivers in synchronised iterations. It adds roles such as the Release Train Engineer and Product Management, and uses prioritisation by WSJF (weighted shortest job first).

Supporters value its clarity and its fit with large organisations. Critics say it can add layers of process and that "agile" becomes a label on traditional planning. Both views are worth hearing; the framework works best where leaders genuinely adopt its values. Read the framework itself at [scaledagile.com](https://scaledagile.com/). Checked on 2026-10-23.

## The main certifications

Certifications show employers that you know the vocabulary and the framework. They do not replace experience. Requirements, prices and exam formats change, so always check the official page. All links checked on 2026-10-23.

| Certification | Body | What it involves (in general terms) | Good for |
|---|---|---|---|
| **PSM I** (Professional Scrum Master) | [Scrum.org](https://www.scrum.org/assessments/professional-scrum-master-i-certification) | An online assessment based on the Scrum Guide; a course is optional; the certification does not expire | A rigorous, lower-cost test of Scrum knowledge |
| **CSM** (Certified ScrumMaster) | [Scrum Alliance](https://www.scrumalliance.org/get-certified/scrum-master-track/certified-scrummaster) | A required live course with a Certified Scrum Trainer, then an exam; renewed periodically | Learning in a classroom with practice and networking |
| **PMI-ACP** (Agile Certified Practitioner) | [PMI](https://www.pmi.org/certifications/agile-acp) | Requires agile project experience and agile training, then an exam covering several approaches (Scrum, Kanban, XP, Lean) | People with experience who want a broad, method-neutral credential, often alongside PMP |
| **SAFe certifications** (for example SAFe Scrum Master, SAFe Agilist) | [Scaled Agile, Inc.](https://scaledagile.com/) | A required course, then an exam; annual renewal | Roles in organisations that use SAFe |

Also worth knowing:

- **PSPO** (Scrum.org) and **CSPO** (Scrum Alliance) for product owners.
- **CAPM and PMP** from PMI for project managers; the PMP covers predictive, agile and hybrid approaches.
- For analysts, the **IIBA** offers the Agile Analysis Certification (AAC) alongside ECBA, CCBA and CBAP. See the [IIBA certifications page](https://www.iiba.org/business-analysis-certifications/).

## Choosing a certification

Ask yourself:

1. **What do job adverts in my area ask for?** Search 20 adverts for your target role and count.
2. **What does my employer use?** A SAFe organisation values SAFe certificates; a startup may not care.
3. **Do I need structured teaching?** Course-based certificates (CSM, SAFe) include it; assessment-only ones (PSM I) let you self-study from the free Scrum Guide.
4. **Do I meet the experience requirements?** PMI-ACP and PMP require documented experience.

For someone starting out, a common route is to read the Scrum Guide closely, practise on real or volunteer projects, then take one entry-level certificate that local job adverts mention.

## Common mistakes

- **Scaling before one team works well.** Scaling a dysfunctional process multiplies the dysfunction.
- **Adopting a framework wholesale** without adapting it to the organisation.
- **Collecting certificates instead of experience.** Interviewers ask for examples, not acronyms.
- **Trusting old blog posts** for exam details; check the official body.

## Quick recap

- Scaling adds coordination across teams; first reduce dependencies by organising around features.
- Scrum of Scrums, Nexus and LeSS keep things light; SAFe is detailed and enterprise-focused.
- PSM I is assessment-based, CSM is course-based, PMI-ACP needs experience, SAFe certificates need a course and renewal.
- Choose by job adverts, employer, learning style and eligibility, and check the official pages.


How agile scales beyond one team (Scrum of Scrums, LeSS, Nexus, SAFe) and how PSM, CSM, PMI-ACP and SAFe certifications compare.

Scaling and certifications

SAFe Explained in Five Minutes

CSM vs PSM: What are they and How do they Compare?

Read velocity, burndown and cycle-time data, set up a board with a workflow, and see how agile scales and which certifications exist.

Agile Delivery: Scrum & Kanban

About this course

Course content

Agile Thinking

Running Iterations

Agile Metrics and Tools

Where this course leads

Next course on the path

Careers that use it