5 Whys Retrospective

The 5 Whys is a root-cause technique: the team starts from one specific problem and repeatedly asks why it happened until it reaches a cause it can act on. In a retrospective it turns a recurring problem into an experiment, without blaming individuals.

Duration
~35 min
Team size
3–8 people
Level
Experienced
Category
Problem-solving

When to use 5 Whys Retrospective

  • A recurring problem the team keeps discussing without fixing.
  • After an incident or a missed goal.
  • When there is one problem to focus on, not a whole sprint to review.

Purpose: Investigate recurring problems and move from symptoms toward underlying causes.

The prompts

  • Problem statement

    Describe one specific problem.

  • Why?

    Why does this happen?

  • Root-cause hypothesis

    What do we believe is the underlying cause?

  • Proposed intervention

    What experiment would address it?

How to run a 5 Whys Retrospective: step by step

  1. 1

    Define one specific problem · 4 min

    Agree on one concrete, observable problem. 'Deploys failed 3 times this sprint' beats 'quality is bad'.

  2. 2

    Gather supporting evidence · 5 min

    Collect facts and data as comments on the problem: when, how often, what impact.

  3. 3

    Explore successive causes · 10 min

    Ask 'why?' on each card. Branch when there are several causes. Stop when you reach something actionable — five is a guide, not a rule.

  4. 4

    Validate the root-cause hypothesis · 8 min

    Pick the deepest credible cause(s). Ask: if we fixed this, would the problem stop? What evidence supports it?

  5. 5

    Design an experiment · 5 min

    Design a small, measurable experiment against the root cause. Define how you'll know it worked.

  6. 6

    Assign ownership & review date · 3 min

    Give the experiment an owner, a review date and a success criterion.

Example

Notes a software team might write:

Problem statement

  • Three releases this month needed a hotfix

Why?

  • Bugs reached production
  • Integration tests didn't run on the release branch

Root-cause hypothesis

  • The release pipeline skips the integration stage

Proposed intervention

  • Run integration tests on every release build for two sprints

Expected outcome: A testable explanation of the problem and a measurable corrective action.

Facilitation tips

  • Five is a guide — stop when the answer is actionable.
  • Follow every branch that has evidence; problems rarely have one cause.
  • Ask 'why did the system allow this?' rather than 'who did this?'. Avoid personal blame.

Running 5 Whys Retrospective in RetroPop

Notes form a cause tree: problem → why → … → root-cause hypothesis → intervention. Branches allow several contributing causes, with evidence added as comments.

Each stage comes with instructions for the facilitator and the participants and a suggested timer you can adjust. Teammates join with a link and their name; no account needed.

Start a The 5 Whys retro

Related