Twenty-two chapters, one team, four Sprints

Turn a business's vague pressure into five drivers you could check in a year.

Beauty Spot's CEO wants an app. Her CMO arrives with a feature list. The first thing the Scrum Master does is refuse to talk about features at all — and the room finds that harder than anyone expected.

What you'll take away

• Why 'what should the app have?' is the wrong opening question
• How to redirect a stakeholder's pet feature without rejecting it
• What to do when the room genuinely can't name a driver
• How to tell a business driver from a business blocker

Get a vision statement people can act on, not a sentence for a slide.

Leadership is asked to fast-forward three years and describe what changed. The adjectives come easily. Turning them into claims somebody could disagree with is the work.

What you'll take away

• The fast-forward question that produces outcomes instead of adjectives
• A frame that forces you to say who benefits, and how
• Why every phrase must trace back to a driver
• Why you keep the messy frame alongside the polished sentence

Choose one Product Goal, and lose three good ideas on purpose.

Four candidate capabilities go on an impact-and-effort matrix. One of them is the Scrum Master's own idea, and it doesn't survive.

What you'll take away

• The difference between a vision and a goal, in practice
• Which parts of this are Scrum and which are practice
• How to turn a priority argument into a picture people can point at
• Why candidates must come from the vision, not from the room

Establish why empiricism applies to leadership as much as to the team.

Everything is agreed and nobody is building yet. The CEO asks how often strategy gets revisited, and the answer turns out to be the most consequential decision in the book.

What you'll take away

• Why transparency, inspection and adaptation only work as a set
• The pillar organisations quietly skip, and what it costs
• The Business Commitment Review: one hour, three questions, monthly
• What a stakeholder actually gains — and why it's not about saving time

Say exactly what Scrum requires, so you can tell it apart from habit.

A reference chapter. Accountabilities, events, artifacts and commitments, stated plainly, with the common misreadings named.

What you'll take away

• Why they're accountabilities and not job titles
• What the Product Owner decides, and what the Developers decide
• Who the Daily Scrum actually belongs to
• Which of your team's rules are Scrum and which are local invention

Write a Definition of Done the team will actually enforce.

Three questions produce the standard, and the third one — what went wrong on past projects — does most of the work.

What you'll take away

• Why a template you hand out gets complied with, not enforced
• The exact difference between the Definition of Done and acceptance criteria
• What happens to work that misses it, with no partial credit
• Why one common line in most Definitions of Done isn't Scrum at all

Break a goal into capability areas before anyone writes a feature.

The goal is too large to build. Decomposing it reveals what the goal implied but nobody wrote down.

What you'll take away

• Why goals without a capability layer produce incoherent products
• The same layer under its other names: themes, initiatives, capabilities
• The cohesive-and-separable test
• How to find what a goal statement left out

Slice a capability into Epics that could each ship alone.

Five Epics come out of one capability area — not by brainstorming, but by walking a user forward and asking what breaks next.

What you'll take away

• Why an Epic is a slice, not a layer
• How much refinement is too early, and how much is too late
• The provocation technique that beats sticky-note brainstorming
• Where Epics sit relative to the Scrum Guide

Write user stories that start a conversation instead of ending one.

Three stories come out of one Epic. The INVEST test gets applied honestly, which means admitting one of them isn't quite independent.

What you'll take away

• Why 'as a user' almost always means nobody thought about who
• The clause that decides whether a story is worth building at all
• How to keep a story a promise rather than a specification
• The phrase that defers an idea without rejecting the person

Write criteria that can fail — and spot the one that commits you to unplanned work.

Twelve criteria for one story. The twelfth points at a screen no story covers. Everybody notices. Nobody acts.

What you'll take away

• The four-part test: binary, observable, implementation-free, necessary
• What scope creep actually looks like from inside the room
• How a criterion can quietly commit you to work nobody planned
• Why criteria and the Definition of Done answer different questions

Decide what an item needs before a Sprint — and why that's contested.

The team estimates in ranges, and one item fails their own readiness check. They take it into the Sprint anyway.

What you'll take away

• Why a formal Definition of Ready is argued about, and when it helps
• Why a single-number estimate hides more than it tells
• Points or hours: the trade-off, and why a new team can't use points
• Why the quietest person in the room isn't the one who thought least

Run a Sprint Planning that produces a goal, not a list of tickets.

Capacity gets calculated out loud. The arithmetic says something has to give, and a story gets split rather than cut.

What you'll take away

• Why starting from the backlog produces a goal written afterwards
• How to calculate capacity so 'does this feel achievable' stops being about mood
• What an honest focus factor looks like
• How to find the cheap part of a story that carries most of the value

Hand the Daily Scrum back to the Developers.

Three transcripts, six days apart. Same team, same fifteen minutes, entirely different meetings. The first one looks fine.

What you'll take away

• The most common Scrum Master mistake, and why it feels like good facilitation
• The one sentence that fixes it, and the silence that follows
• How to tell an impediment from a problem
• Why the three questions were removed from the Guide in 2020

Run a Sprint Review that inspects the business, not just the software.

The demo works. The Product Owner accepts it. One developer says the thing nobody wants to say — and then the drivers go up on screen.

What you'll take away

• Why acceptance criteria stop getting checked when people are pleased
• The question that separates a Review from a demo
• How to hear the substance in an unfair piece of stakeholder feedback
• Why an effort report you produce once becomes expected forever

Get a team to say true things, then change exactly one.

Four people, four admissions, no defensiveness. Then four candidate improvements, and a Scrum Master who insists on picking one.

What you'll take away

• The prime directive, and why the meeting doesn't work without it
• How psychological safety is built before the Retrospective, not in it
• Why one improvement beats three agreed ones
• The five ways Retrospectives die, including the one that looks like success

Learn where process stops working, and what replaces it.

Every acceptance criterion is met. Then the Head of Retail Operations asks what happens at a till on a sunny afternoon.

What you'll take away

• Why a Definition of Ready gate works, and exactly where its ceiling is
• The difference between known unknowns and the other kind
• How to narrow a story to what you can actually verify
• Why 'how did we not think of that?' is nearly always an invitation problem

Stop impediments from disappearing into somebody's inbox.

A blocker sits for four days because everyone assumed somebody else had it. Seek, Swarm, Solve, Shield.

What you'll take away

• Why a blocked card without an explanation gets worked around
• How to swarm without turning the Daily Scrum into a problem-solving session
• Equipping an escalation instead of owning it
• What to write on the card so it can't go quiet

Protect the Sprint without ever saying no.

A stakeholder goes around the Product Owner and straight to the CEO. What happens next isn't an escalation.

What you'll take away

• Buffer versus gatekeeper, and why the distinction matters
• How to spot borrowed authority — 'the CEO loves it'
• Why 'we can't' is both wrong and unnecessary
• The single question that ends most mid-Sprint requests

Create ownership by removing yourself, and tolerating the silence.

The team keeps asking permission. The Scrum Master examines the one variable he can actually change: his own behaviour.

What you'll take away

• Why ownership can't be granted by announcement
• Which of your habits are teaching the team to defer to you
• How to give the what and leave the how alone
• Why the silence after you stop answering is the point

Hold the line on Done when everyone has a good reason not to.

Something is almost finished, the Review is tomorrow, and the pressure to call it Done is entirely reasonable.

What you'll take away

• Why 'almost done' is a warning rather than a status
• Where a Definition of Done has to live to be used
• How to defend it without turning it into a weapon
• Who owns quality, who confirms value, and in which order

Miss a Sprint Goal without losing the room.

The goal isn't going to be met, and it's day seven. What the team does next determines whether anybody trusts the next forecast.

What you'll take away

• Why a team that never misses a Sprint Goal is sandbagging
• Renegotiating on day seven instead of surprising people on day ten
• How to frame a Review before the demo so there's no suspense
• What actually changes a stakeholder's mind — and it isn't your explanation

Decide honestly which of this you can drop, and which you can't.

Not every team needs every artifact. The chapter names what compresses, what doesn't, and when Scrum is the wrong answer entirely.

What you'll take away

• Why the questions never drop even when the artifacts do
• What compresses naturally in a small team, and what never does
• The four factors that decide how much formality you need
• The compression test to run before dropping anything