What needs to be finished first
The problem is formulated as an observable symptom with date, frequency, and impact in one sentence.
For tightly bounded symptoms with a clear causal chain, check whether 5 Whys is sufficient and whether Fishbone adds value through broader categorization.
What needs to be ready before start
Whiteboard or Miro board with a pre-drawn Fishbone (head on the right, spine horizontal, 4-6 ribs); stickies; markers; timer; link to logs, tickets, or data that can support causes.
One facilitator, who separates categories from severity judgment; two to eight participants with direct process involvement (Operations, Engineering, Quality, Support); one scribe for clean transcription.
Problem sentence with time, frequency, and impact; known prior hypotheses; access to data (logs, KPIs, incident reports); list of people who worked close to the problem in the last four weeks.
30-60 min
Write problem in Fishbone head. Choose categories (classically 6Ms: Methods, Machines, Materials, Manpower, Measurement, Milieu; alternatively 4Ps for services). Set timer for first collection phase.
The one question this method answers
Which possible causes across all relevant categories deserve data-driven deep validation as the next action?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Clarify the problem | 5 min | Read and test the problem sentence, checking whether it is an observable symptom with time and impact. If not, rewrite it. | "Performance is poor" is not a symptom. "P95 API latency on /orders > 800 ms since 2026-05-10" is. Without a symptom there is no Fishbone. |
2Phase 2: Choose categories | 5 min | Define 4-6 categories as ribs. Use classic 6Ms for production, 4Ps (People, Process, Policy, Place) for services, or custom categories for context. | More than six categories overloads participants. If a category stays empty, it is likely irrelevant for this problem and should be removed. |
3Phase 3: Collect causes | 20-30 min | Collect causes for each category for 5 minutes each, then share in sequence. Add causes as stickies on each rib. For each main cause, add 2-3 sub-causes (Why). | If all causes land in one category, the group is one-sided or has a preformed model. Explicitly probe other categories. |
4Phase 4: Prioritize | 10 min | Mark causes by (a) likelihood and (b) data availability for verification. Label top 3-5 causes with owner and investigation method. | Prioritize by likelihood, not favorite hypothesis. If no data is available, treat the cause as an investigation task, not an action. |
5Phase 5: Follow-up | 5-10 min | Create investigation backlog: one concrete check action (log query, experiment, interview) per top cause with due date. Store the clean diagram as artifact. | A Fishbone without investigation backlog stays a nice sketch. At least three investigation actions with dates are required for diagnostic value. |
What comes out at the end
Refined Fishbone diagram with problem statement in the head, labeled ribs per category, all causes and sub-causes collected, top 3-5 highlighted, and separate investigation backlog with owner, method, and due date.
One entry per investigation case with date and problem ID. Follow-up sessions after data checks should create Version 2, adding new findings and marking disproven causes instead of deleting them.
Compact working template for Fishbone Diagram with problem, cause categories, evidence, and next investigation.
Surface possible cause categories and likely root causes for a problem.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Problem: Since 2026-05-10, P95 latency on /orders has been continuously above 800 ms (before 220 ms), with 4% additional checkout abandonment as impact.
Categories (adapted 6Ms):
Top 3 causes (prioritized):
Recognize symptoms and steer against them
Fishbone head says "App is slow" or "customers are dissatisfied" without time, frequency, or metric.
Pause and restate symptom with date, frequency, and measurable impact. Without a symptom, you get cause speculation instead of analysis.
Stickies contain actions ("add index") rather than causes ("missing index on customer_id").
Separate cause and intervention. Place cause on the rib and solution in a separate list. Fishbone analyzes why, not how.
The group forces causes into incompatible categories to fill all ribs.
Empty ribs are allowed and can indicate relevant categories. Wrongly assigning entries distorts prioritization. Categories are support, not quotas.
Top cause is the one defended with the loudest voice rather than most likely.
Use silent dot voting by likelihood first. Use data availability as a second criterion. Vote on both separately, then combine.
Workshop ends with top 3 causes but no one verifies them with logs or experiments; the diagram goes to archive.
Investigation backlog is mandatory. For every top cause, define a concrete check with owner and date. Document review one to two weeks later.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.