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

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.