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

Agile Delivery: Scrum & Kanban

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.