Five Whys

What is the 5 whys?

The 5 whys is a root cause analysis technique that asks “why?” repeatedly — usually about five times — to drill past the visible symptoms of a problem down to the underlying cause you can actually fix. Each answer becomes the question for the next “why”, so a chain of cause and effect emerges from the surface problem to its root.

Developed by Sakichi Toyoda and used as part of the Toyota Production System, it is deliberately simple: no special tools, just persistent questioning. Its power is in resisting the urge to fix the first symptom you see and instead following the trail to the cause that, if addressed, stops the problem coming back.

Key takeaways

• The 5 whys asks “why?” repeatedly to reach a problem’s root cause.
• Each answer feeds the next “why”, forming a chain from symptom to cause.
• “Five” is a guideline — stop when you reach a cause you can act on.
• It’s a sibling of the fishbone diagram: 5 whys goes deep, fishbone goes broad.
• Best paired with agreed corrective actions that address the root cause.

Why use the 5 whys?

The 5 whys is a simple technique that helps a team:

• Move past symptoms to the cause that actually needs fixing.
• Avoid firefighting the same problem again and again.
• Reach a root cause quickly, with no special tools or training.
• Build shared understanding of how a problem happened.
• Point corrective action at the real cause, so fixes stick.

Who should use the 5 whys?

It suits any team investigating why something went wrong — engineering teams in incident reviews and post-mortems, agile teams in retrospectives, operations and quality teams chasing recurring defects, and any manager unpicking a missed goal or a customer complaint. It is a natural fit for facilitators and scrum masters running a root cause discussion.

It works best on problems with a fairly linear cause. For failures with many interacting causes, use it alongside broader methods rather than on its own.

How the 5 whys works

You start with a clear statement of the problem, then ask “why did this happen?” You take the answer, ask “why?” of that, and repeat. Each step should be grounded in fact, not guesswork.

The root cause here is not “the server ran out of disk” — that is a symptom. It is the missing provisioning checklist. Fix that (and add disk-usage alerting) and this whole class of failure is far less likely to recur.

Worked example: a recurring late delivery

A team keeps missing its sprint commitments and runs a 5 whys in the retrospective:

• Problem: We missed the sprint goal again.
• Why? Two key stories weren’t finished.
• Why? They turned out to be much bigger than estimated.
• Why? We didn’t understand the requirements when we estimated.
• Why? The stories came into the sprint without acceptance criteria.
• Why? We don’t have a definition of ready, so anything can be pulled in.

The root cause is the missing definition of ready — not “developers are slow”. The corrective action is concrete: agree a definition of ready and refuse to pull stories that don’t meet it. That addresses the cause, not the symptom.

How to run a 5 whys in GroupMap

State the problem clearly at the top of a board and invite the team in with a link or password. Ask “why?” and let everyone contribute answers at the same time, then agree the most likely one and ask “why?” of that — building the chain together, grounded in what people actually know rather than one person’s assumption.

When the chain reaches a cause you can act on, confirm it as the root cause and brainstorm corrective actions. Capture those as owned action items with timeframes, so the analysis leads to a fix rather than a nod of agreement that changes nothing.

Limitations of the 5 whys

The 5 whys is quick and useful, but it has real limits:

1. It tends to follow a single path, so it can miss other contributing causes — pair it with a fishbone for breadth.
2. Results depend on the knowledge in the room; the chain is only as good as the people building it.
3. It can stop at a convenient answer rather than the true root cause if the facilitation is loose.
4. For complex, safety-critical, or multi-cause failures, it should support a fuller investigation, not replace it.

Related templates

• Fishbone (Ishikawa) root cause analysis
• Corrective action plan
• Start, stop, continue retrospective

References

• The Toyota Production System — Toyota
• Five Whys — Mind Tools

Get to the real cause with GroupMap

The 5 whys works best when the whole team builds the chain together and grounds each step in what they actually know. GroupMap lets everyone contribute answers at once, keeps the why-chain visible to the group, and captures the corrective actions the root cause demands. Instead of one person’s theory or a quick blame, you get a shared, evidence-based root cause — and the agreed actions to stop the problem coming back.