Session Brief: 5 Whys

Goal

Artifact: Root cause notes

Working Question

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

Context

A concrete problem as one sentence with date and impact; incident ID or ticket link; relevant logs or graphs from the last 24 hours; known workarounds.

Setup

• Format: Method session
• Duration: 15-30 min
• Mode: Workshop
• Participants: 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.
• Owner: One facilitator who guides the chain and asks neutral follow-up questions
• Participation mode: Team round, shared work and alignment
• Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Root cause notes. After the session, the artifact should be shareable, reviewable, or reusable.

Input

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

Preparation

Write the problem sentence in the first box at the top. Five empty boxes vertically below it. Timer set to 20 min. Rule: no names, only mechanisms. Each answer becomes the starting point for the next Why question.

Agenda

1. 0-2 min (2 min) Owner: Facilitator Action: Formulate the problem as an observable symptom: what, when, how often, and what effect. No guesses about causes. Hint: If the sentence already contains a cause ('because X was broken'), rewrite it. Otherwise the chain starts too late. Output: Root cause notes

2. 2-15 min (13 min) Owner: Facilitator Action: Build the Why chain: one Why question and one answer per box, consistently focused on mechanisms instead of people. After each Why, check whether the answer can be supported by logs or data. Hint: By the third Why at the latest, the answer should become technical or process-related. If it stays at the behavioral level, data access or system knowledge is missing. Output: Countermeasures

3. 15-22 min (7 min) Owner: Facilitator Action: Check the stop criterion: Is the lowest answer changeable by the team itself? If not, go back one Why or branch the path. Hint: A chain often ends too early at 'the service is old.' That is not a controllable cause; either continue or open a second chain in parallel. Output: Root cause notes

4. 22-30 min (8 min) Owner: Owner Action: Note one to three concrete countermeasures, each with owner and target date. The countermeasure must address the identified cause, not the symptom. Hint: If the countermeasure is 'improve monitoring', it is a detection measure, not a cause fix. Note both and keep them separate. Output: Countermeasures

5. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Root cause notes

Closeout

• Update result artifact: Root cause notes
• Define location, version, and review recipients.
• Define owner, next step, and review date.

Root cause notes: 5 Whys

Working Question

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

Context

A concrete problem as one sentence with date and impact; incident ID or ticket link; relevant logs or graphs from the last 24 hours; known workarounds.

Participants

• Owner: One facilitator who guides the chain and asks neutral follow-up questions
• Participants: 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.

Input

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

Template

5 Whys Working Template

Goal

A simple technique for moving from symptoms to underlying causes.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

• Root Cause Notes:
• Countermeasures:

Assumptions and open questions

• ...

Decision / Next step

Owner, date, and success signal.

Completion Check

• Root cause notes is complete enough for review:
• Location:
• Version / status:
• Review by:
• Next step:

Next Step

• Review result
• Mark open questions
• Schedule review or decision