5 Whys Root Cause Analysis

Ask why until you reach a cause you can fix.

Try this retrospective live

Problem statement

What exactly happened, where and when?

Release 4.2 shipped two days late, the third late release this quarter.
Checkout errors rose to 3% of orders after Tuesday's deploy.
Forty support tickets waited more than 48 hours for a first reply last week.
What we know

Which facts and data describe the problem?

The build was green on Friday, and the release branch was cut on Monday.
Error logs show timeouts from the payment provider starting at 14:05.
Two of our four reviewers were on leave that week.
Why did it happen?

What directly caused the problem?

Final testing started late because the last feature merged on release day.
The new retry setting flooded the payment provider's API with requests.
Nobody was on the support rota on Monday mornings.

What is the 5 Whys technique?

The 5 Whys is a root cause analysis technique. You state a problem, ask why it happened, then ask why again of each answer until you reach a cause the team can fix. It comes from the Toyota Production System, and Taiichi Ohno's own 5 whys example follows a stopped machine through a blown fuse, a dry bearing and a worn pump shaft to the root cause: no strainer on the pump. This 5 whys template runs the whole chain in one TeamRetro retrospective. Write the problem statement in the first column and the facts you already have in the second. Everyone then answers the first why, "Why did it happen?", in the third column. The team groups the answers and votes for the most likely cause. In Discuss, you open that card and ask the next four whys as a comment thread on it, each answer a reply to the one before. The last reply is your root cause, and you copy it to an action with an owner and a due date. The 5 Whys works best when a problem follows one main line of cause and effect: a late release, a repeat incident, a defect that escaped testing. Following one chain to its end stops the team settling for the first answer, and it moves the discussion from who made a mistake to what in the process allowed it. When a problem has many contributing causes, map them first and then run the 5 Whys on the most likely ones.

5 Whys retrospective format

Problem statement

What exactly happened, where and when?

Agree one problem statement before anyone adds a cause, and keep it to a single card. Make it specific: what happened, where, when and how big, with no guess at the cause. "Release 4.2 shipped two days late" gives the team something to ask why about. "Releases are a mess" does not.

What we know

Which facts and data describe the problem?

Collect facts before causes, such as timelines, metrics, logs, customer reports and what changed recently. Every answer in the chain of whys should rest on something here or something the team can check. If a fact is missing, note it and make finding it an action.

Why did it happen?

What directly caused the problem?

Each card here is a first why, a direct cause of the problem statement. Keep answers to what happened, not who. After grouping, vote for the cause most likely to explain the problem. In Discuss, open the top card and ask the next four whys as a comment thread, each answer a reply to the one before. If two answers both hold at one level, reply to the same comment twice and follow each branch.

When to use this retrospective

  • A problem keeps coming back after it was fixed, and you want to find the cause the last fix missed.
  • After an incident, an escaped defect or a missed deadline, when the team needs to know why before it agrees what to change.
  • One item in a retrospective got most of the votes and deserves a proper look in its own session.
  • The problem looks like it has one main line of cause and effect. If it has many contributing causes, map them with a fishbone diagram first.

Suggested icebreaker questions

  • What's a small fix you once made that solved a much bigger problem?
  • What's something you only understood after asking why more than once?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Agree the problem statement out loud before the brainstorm and add it as the only card in Problem statement. The template sets the brainstorm to Show ideas immediately, so everyone sees each card as it's added. You can change it in the meeting settings.
  • The template sets the Discuss phase to Discuss all, so the problem statement and the facts stay on screen beside the top-voted cause. You can change it in the meeting settings.
  • Run the chain as a comment thread on the top-voted cause. That card is the first why. Add a comment answering "Why did that happen?", reply to it with the next answer, and keep replying. Replies nest three deep, so the card, one comment and three replies give you five whys.
  • Stop when you reach a cause the team can change, whether that takes three whys or seven. If you need a sixth, add a new comment on the card that carries on from the last reply.
  • Ask about the process, not the person. If an answer lands on "someone made a mistake", ask why the process let that mistake through.
  • Turn the root cause into a countermeasure. Open the menu on the last reply, choose Copy to action, and give the action an owner and a due date. Review it in the Open Actions phase of a later retrospective to check the fix worked.

Frequently asked questions

What is Taiichi Ohno's 5 Whys technique?
It's the practice of asking why again and again when a problem occurs, to get past the obvious symptom to the root cause. It is part of the Toyota Production System, which Taiichi Ohno helped establish, and his example of a stopped machine reaches the root cause, a pump with no strainer, on the fifth why.
How can the 5 Whys be used?
Start with a specific problem, ask why it happened, then ask why of each answer until you reach a cause you can fix. A 5 whys example: the release was late because testing started on release day, because the last feature merged that morning, because it waited three days for review, because only one person can approve database changes, because nobody else has been trained on the schema. The fix is to train a second approver, not to ask people to test faster.
What are the techniques of root cause analysis?
Common techniques are the 5 Whys, the fishbone (Ishikawa) diagram, Pareto analysis, fault tree analysis and change analysis. The 5 Whys follows one chain of cause and effect, so when a problem has several contributing causes, map them first with a Fishbone (Ishikawa) Retrospective and then run the 5 Whys on the most likely ones.
How do you write a root cause analysis?
State the problem with facts: what happened, where, when and how big. Trace the causes back to a root cause, checking each step against evidence, then record the corrective actions with owners and due dates and how you will check they worked. In this template the problem and facts are columns, the comment thread on the top cause is the chain of whys, and the actions are the corrective actions.
What is the best template for root cause analysis?
It depends on the problem. A 5 whys template suits a problem with one main line of cause and effect, and a fishbone diagram suits a problem with many possible causes across people, process and tools. Either works best when the team fills it in together, with the facts in front of them and an owner for every fix.

Related templates

Four Ls Retrospective

Reflect on what your team Liked, Learned, Lacked and Longed for

Agile Retrospective

Four questions to review your last sprint and plan changes.

Anchors & Engines Retrospective

See what's driving your team forward and holding it back

Cross-Team Collaboration Retrospective

Fix the friction between teams that depend on each other

Ready to run this retrospective?Try this retrospective live