methodatlas
Method guideOperations

5 Whys

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityLow
Time15-30 min
Participants2-6
FormatWorkshop
MaturityCanonical
Plan session
01

Prerequisite

What needs to be finished first

Complete firstConcrete case

An observed deviation with timing, impact and expected standard is bounded.

Without a concrete case, the analysis becomes a general discussion of possible causes.
Complete firstAccess to evidence

A timeline, logs, metrics, configuration or observations and direct process or system knowledge are available.

Without evidence, the chain can sound plausible while remaining untestable.
02

Preparation

What needs to be ready before start

Materials

Whiteboard or Miro board with a vertical chain of six boxes (Problem + 5 Whys); pen; timer; link to the triggering ticket or incident report.

People / roles

One facilitator who guides the chain and asks neutral follow-up questions; two to five people with direct system contact (at least one engineer, one operator); a scribe who writes down every answer verbatim.

Pre-read

Gather the incident or ticket link, a timeline from first symptom to stabilization, the standard, relevant states and known workarounds. Separate evidence, interpretation and open assumptions before starting.

Time needed

15-30 min

Setup

Write the problem and standard at the top of a board or page, then leave space for the causal chain, evidence status, counter-hypotheses and measures. Do not use people as causes; keep detection, containment and cause removal distinct.

03

Core question

The one question this method answers

Which controllable cause behind the symptom can the team fix with a concrete countermeasure?

04

Flow

Phases with goal, actions, output and pitfall

5 Whys examines the causes of a clearly bounded problem through successive why questions. The number five is a reminder. The analysis continues until it reveals an evidenced condition within the team’s influence.

  1. 1

    Frame

    Clarify problem and standard

    Goal

    Create a shared, observable problem definition with location, timing, scale and expected condition.

    Inputs for this step

    • Incident, quality deviation or process problem
    • Standard or expected condition
    • Timestamp, impact and case boundary

    Actions

    • Describe what happened, when, where and with what impact; remove cause and blame from the opening sentence.
    • Write the expected condition beside the deviation.
    • Clarify scope, decision authority and participants; collect data first when the symptom is unclear or cannot be reproduced.

    Output

    Problem definition

    Observation · standard · deviation · scope

    Quality check

    Could an outside person recognize the case without inheriting a suspected cause from the problem statement?

    Pitfall

    If the problem already says “because the service was misconfigured” or “someone failed to pay attention,” the problem statement already contains a suspected cause. State only observation, timing, impact and standard, and collect suspicions as later hypotheses.

    Timing: 3–5 minutes; narrow the case before starting the chain when the problem is unclear.

  2. 2

    Evidence

    Establish the point of occurrence

    Goal

    Locate and describe the deviation from facts, observation and expertise so the first why starts at the right point.

    Inputs for this step

    • Problem definition and timeline
    • Logs, metrics, configuration or work observation
    • People with direct process or system knowledge

    Actions

    • Reconstruct the flow up to the point of occurrence and record relevant states.
    • List possible contributing factors and test them against data or observation where possible.
    • Keep evidence, interpretation and open assumption visibly separate.

    Output

    Evidenced starting picture

    Point of occurrence · facts · tested factors · open assumptions

    Quality check

    Can the group show where the deviation occurred and which evidence supports the starting picture?

    Pitfall

    If the group starts with plausible explanations in the meeting room while timeline and logs are missing, the starting picture rests on assumption instead of evidence. Pause the analysis and reconstruct the starting picture from work or system data with evidence.

    Timing: 5–10 minutes; plan a separate observation or evidence-gathering step when data is hard to access.

  3. 3

    Trace

    Trace the causal chain

    Goal

    Develop a connected cause-and-effect chain whose links are supported by evidence, expertise or clearly marked assumptions.

    Inputs for this step

    • Evidenced starting picture
    • Timeline and contributing factors
    • People with technical or domain detail

    Actions

    • For the current answer, ask which condition enabled it and record that answer as the next starting point.
    • After each link, read the causal direction upward with “therefore” and add evidence or a test action.
    • Branch when multiple plausible paths matter instead of forcing one linear story.

    Output

    Causal chain

    Observation → condition → next cause · evidence status for each link

    Quality check

    Does every link explain how the prior deviation could occur, with a clear distinction between supported, inferred and open?

    Pitfall

    If the chain jumps to statements such as “the process is old” or stops at the first repair, a traceable mechanism between the steps is missing. Ask for a concrete mechanism and continue the chain to an influence boundary or a testable limit.

    Timing: 8–15 minutes; do not limit the work to a fixed question count. Stop on evidence and influence, not arithmetic.

  4. 4

    Challenge

    Test the explanation and boundary

    Goal

    Narrow the cause or set of causes until it is plausible, testable and actionable for the team.

    Inputs for this step

    • Causal chain with evidence status
    • Alternative hypotheses
    • Knowledge of the actual influence boundary

    Actions

    • Ask for alternative explanations and counter-evidence; do not treat agreement as confirmation.
    • Check whether the lowest condition explains recurrence and can be changed by the team.
    • When the cause is outside the team’s influence, choose an influenceable precursor, investigate further or hand the case to a better-suited analysis.

    Output

    Tested cause statement

    Preferred explanation · counter-evidence · uncertainty · influence boundary

    Quality check

    Are uncertainty, alternatives and influence documented openly instead of claiming unsupported certainty?

    Pitfall

    If the group names the first plausible answer the root cause, it confuses consensus with evidence. Check the chain backward against data, invite counter-hypotheses, and label missing evidence openly.

    Timing: 5–10 minutes; extend or stop when the paths remain branched or weakly supported.

  5. 5

    Act

    Set countermeasures and learning

    Goal

    Agree on measures that change the investigated condition or protect detection until then, with a checkable effect.

    Inputs for this step

    • Tested cause statement
    • Available options and constraints
    • Owner, due date and suitable effect indicators

    Actions

    • State at least one measure that addresses the cause; name detection, containment and cause removal separately.
    • Set owner, due date, expected effect and review date.
    • After implementation, check whether the deviation recedes and update the analysis when it does not.

    Output

    Countermeasure and learning plan

    Cause measure · containment · owner · due date · evidence of effect

    Quality check

    Does the measure address the tested condition, and is it clear how the team will see its effect and side effects?

    Pitfall

    If the only countermeasure is monitoring, a hotfix, or training, the actual enabling condition remains unchanged. Secure detection and containment separately and add an owned measure for the cause or missing safeguard.

    Timing: 5–10 minutes; scale measures and review timing to risk and influence.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

5 Whys · Root Cause AnalysisMove from visible symptom to a steerable cause and countermeasure
5 Whys UrsachenanalyseDie Skizze zeigt eine Warum-Kette vom sichtbaren Symptom über fünf Fragen zu einer steuerbaren Ursache und einer Gegenmaßnahme.Vom Symptom zur steuerbaren UrsacheJede Antwort wird zur nächsten Frage. Stoppen, wenn eine wirksame Gegenmaßnahme möglich wird.SymptomSichtbares Problem sauber formulieren1Warum ist das passiert?Direkte Beobachtung2Warum war das möglich?Nächste Bedingung3Warum bestand diese Bedingung?Prozess oder Kontext4Warum blieb es unentdeckt?Kontrolle oder Feedback5Warum ist es steuerbar?Ursache mit HebelSteuerbare Ursachebelegbar, beeinflussbar, nicht blame-orientiertGegenmaßnahmeMaßnahme an Ursache koppeln
Form

A traceable analysis record with problem definition, evidenced causal links, uncertainty, influence boundary and countermeasures with owner, due date and later effect check.

Versioning / ownership

Date, incident ID, and decider in the header. Add later corrections as an edit log at the end, do not overwrite. With new insights, set status to `revised` and keep the original chain.

Tool alternatives
  • Markdown in the repo under docs/incidents/
  • Confluence page in the postmortem space
  • Miro board with snapshot export
  • Linear or Jira issue with the Why chain in the body

5-whys-working-template.md

Prepare a selected step or the complete flow. Your ready-to-use plan takes shape on the right.

5 Whys: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Entire analysis Time: 15–30 minutes for a bounded case; add evidence gathering and effect review.

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Whiteboard or Miro board with a vertical chain of six boxes (Problem + 5 Whys); pen; timer; link to the triggering ticket or incident report.
  • Roles: One facilitator who guides the chain and asks neutral follow-up questions; two to five people with direct system contact (at least one engineer, one operator); a scribe who writes down every answer verbatim.
  • Advance information: Gather the incident or ticket link, a timeline from first symptom to stabilization, the standard, relevant states and known workarounds. Separate evidence, interpretation and open assumptions before starting.
  • Overall time needed: 15-30 min
  • Setup: Write the problem and standard at the top of a board or page, then leave space for the causal chain, evidence status, counter-hypotheses and measures. Do not use people as causes; keep detection, containment and cause removal distinct.

Prepare for the work steps

Frame: Clarify problem and standard

  • Incident, quality deviation or process problem
  • Standard or expected condition
  • Timestamp, impact and case boundary

Evidence: Establish the point of occurrence

  • Problem definition and timeline
  • Logs, metrics, configuration or work observation
  • People with direct process or system knowledge

Trace: Trace the causal chain

  • Evidenced starting picture
  • Timeline and contributing factors
  • People with technical or domain detail

Challenge: Test the explanation and boundary

  • Causal chain with evidence status
  • Alternative hypotheses
  • Knowledge of the actual influence boundary

Act: Set countermeasures and learning

  • Tested cause statement
  • Available options and constraints
  • Owner, due date and suitable effect indicators

Frame: Clarify problem and standard

Expected artifact: Problem definition

Observation · standard · deviation · scope

Entry:

...

  • Could an outside person recognize the case without inheriting a suspected cause from the problem statement?

Evidence: Establish the point of occurrence

Expected artifact: Evidenced starting picture

Point of occurrence · facts · tested factors · open assumptions

Entry:

...

  • Can the group show where the deviation occurred and which evidence supports the starting picture?

Trace: Trace the causal chain

Expected artifact: Causal chain

Observation → condition → next cause · evidence status for each link

Entry:

...

  • Does every link explain how the prior deviation could occur, with a clear distinction between supported, inferred and open?

Challenge: Test the explanation and boundary

Expected artifact: Tested cause statement

Preferred explanation · counter-evidence · uncertainty · influence boundary

Entry:

...

  • Are uncertainty, alternatives and influence documented openly instead of claiming unsupported certainty?

Act: Set countermeasures and learning

Expected artifact: Countermeasure and learning plan

Cause measure · containment · owner · due date · evidence of effect

Entry:

...

  • Does the measure address the tested condition, and is it clear how the team will see its effect and side effects?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/5-whys/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

5-whys-beispiel.md

Concrete filled scenario, fictional example

Problem

Between 09:12 and 09:47 UTC on 14 May, about 8% of checkout requests failed.

Causal chain

The database call timed out → the connection pool was exhausted → a batch held online connections too long. Evidence status: logs confirmed; missing pool separation remains a condition to test.

Next step

Measure the batch pool usage and assess a separate quota as a countermeasure. Owner: Operations, review date: 21 May.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Clarify problem and standardIf the problem already says “because the service was misconfigured” or “someone failed to pay attention,” the problem statement already c…View in phase
  2. Establish the point of occurrenceIf the group starts with plausible explanations in the meeting room while timeline and logs are missing, the starting picture rests on as…View in phase
  3. Trace the causal chainIf the chain jumps to statements such as “the process is old” or stops at the first repair, a traceable mechanism between the steps is mi…View in phase
  4. Test the explanation and boundaryIf the group names the first plausible answer the root cause, it confuses consensus with evidence.View in phase
  5. Set countermeasures and learningIf the only countermeasure is monitoring, a hotfix, or training, the actual enabling condition remains unchanged.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The problem and expected standard are clear, including timing and impact.
The point of occurrence and relevant states are supported by available evidence.
Each important causal link is marked as supported, inferred or open.
Influence boundary, counter-hypotheses and remaining uncertainty have been reviewed together.
Cause measure, containment, owner, due date and effect check are agreed.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.