5 Whys Template: From Symptom to Root Cause

The 5 Whys is the simplest root-cause method there is: state the problem, ask why it happened, then ask why that happened, until the answer is something your team can change. The board has four columns: What happened, Why?, Root cause and How we prevent it. Use it on one specific problem, like a bug that reached customers.

The four columns

How the board maps to the classic method. The classic method is one written chain from problem to countermeasure. On the board, the chain lives in the second column. Number each note ("Why 1:", "Why 2:"), because the board sorts by votes or newest, not by sequence. When a why has two honest answers, branch into "Why 3a" and "Why 3b" and group each branch's notes.

Where it comes from. Taiichi Ohno, who built the Toyota Production System, described asking why five times in Toyota Production System: Beyond Large-Scale Production (Japanese edition 1978, English 1988). In his example, a machine's blown fuse traces back through a worn pump shaft to a missing strainer that let metal scraps in. Replace the fuse and the machine stops again; fit the strainer and it doesn't. The Lean Enterprise Institute notes that the number five isn't the point.

When to use it (and when not to)

Use it when:

• one problem keeps coming back and the team keeps fixing the symptom
• a bug reached customers and you want to know why your tests, reviews and alerts missed it
• the top-voted problem from your last retro is one nobody can explain

Pick something else when:

• the problem has many interacting causes. Lay them out with a fishbone, then run 5 Whys on the top-voted one.
• it was an outage with several responders. Run an incident review; one chain flattens a messy event.
• people are upset with each other. A why chain under stress ends at a name. Start with Mad Sad Glad.

Known limits. Alan Card's "The problem with '5 whys'" (BMJ Quality & Safety, 2017) argues that the method squeezes complex problems into one causal chain and that stopping at the fifth why is arbitrary. John Allspaw's "The Infinite Hows" (2014) adds that why questions drift toward blame and hindsight, and suggests asking how: how did this make sense to the people involved at the time? Treat your chain as one explanation, not the only one.

How to run it live (45 minutes)

1. Carry-over. Open the Action Items panel and check Previous Retro and Old / Unresolved Items. An open fix from an earlier 5 Whys may be why the problem is back.
2. Pin down the problem. "Deploys are flaky" is a topic. "Three of last week's eight deploys were rolled back" is a problem.
3. Ask why, out loud. The facilitator types each answer as a numbered note and asks: fact or guess? Mark guesses "(check)".
4. Vote on where to stop. Dot voting, two votes each. The stop point is the deepest answer the team can change that would have prevented the problem.
5. Prevent, don't patch. "Fix the template" is a patch. "A CI test that renders every template" is prevention. Only the second goes in the last column, and each one gets an owner.

How to run it async over a sprint

Each why depends on the last answer, so build the chain live. Use async to collect the facts beforehand.

1. When the problem shows up: starting a retro closes the board in progress, so make 5 Whys your next retro: pick it with Try a different format when you click Start New Retro, then post the problem in What happened, with the number that shows its size.
2. Over the next few days: people add facts as they find them, like log lines and ticket links. Theories go in the Why column marked "(guess)". Turn off Show Name to post your own part in it without your name shown.
3. Mid-sprint: the facilitator asks for the missing fact, such as when the template tests were removed.
4. Meeting day: everyone votes on the likeliest guesses beforehand, then a 20-minute call builds the chain. More in how to run an async retrospective.

9 example prompts

What happened

1. What exactly did the user see, and when?
2. How big was it: how many users, requests or tickets?

Why? (keep asking) 3. Why did that happen, and what's the evidence? 4. Why didn't our tests, reviews or alerts catch it? 5. How did this make sense to the person at the time?

Root cause 6. If we fixed only this, would the problem have been prevented? 7. Did we stop at a person? What made the mistake easy to make?

How we prevent it 8. What would stop this and similar problems, not just this one? 9. How will we know in a month that the fix worked?

For more, see 60 sprint retrospective questions.

Facilitator tip and a common pitfall

Tip: stop at the deepest cause you can still act on. The chain can always go deeper: no owner because the team split, the split because of a reorg. Stop where the team can act this quarter.

Pitfall: the chain ends at a person. "Why 3: Dana didn't run the email tests" isn't a root cause; it's where the questions stopped. Ask what Dana saw and what would have made the missing test obvious. The answer is usually a gap in tooling or process.

How AI helps with this format

On Pro AI (and during the free trial), CarrotIQ takes care of the write-up:

• Group names. Group a branch's notes and CarrotIQ names it, for example "Untested Email Templates", so two branches read as two stories.
• Summaries. The Sprint Summary covers each column and the whole retro, a ready write-up for the bug ticket.
• Suggested action items. CarrotIQ Suggest drafts an action from the most-voted notes. It can't tell a fact from a guess, so check the chain first.

Example action items

See retrospective action items that actually get done.

Use this template in Retro Rabbit

1. Start a 14-day free trial. No card is needed.
2. For one retro, click Try a different format in Start New Retro and pick 5 Whys: it applies to that retro only, and your Team Room keeps its usual columns. To make it the room's format, choose it under "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
3. In the same dialog, name the retro after the problem, such as "Blank reset emails, Oct 14", so it's easy to find later.

See pricing for plans.

Related formats

• Fishbone: when there are many possible causes
• Incident Review: for outages with a timeline
• Project Post-Mortem: for a whole project, not one problem
• More formats in Incidents and postmortems
• All retrospective templates