Fishbone diagram

An Ishikawa diagram puts the problem at the head of a spine and groups possible causes along it. The categories are the trick: they stop a root cause session from becoming a list of whatever people thought of first.

Use the traditional six categories or agree your own before you start.

#When to reach for one

• Root cause analysis after an incident or a quality problem.

• Structured problem solving where the causes span several areas.

• Workshops where the discussion needs categories to stay balanced.

#How to draw it in Capable

#A worked example

Causes grouped by category, feeding one effect:

The source, which you can paste into a new diagram and edit:

flowchart LR
  P[People] --> E([Checkout failures])
  M[Process] --> E
  T[Technology] --> E
  D[Data] --> E
  P --> P1[No on-call runbook]
  P --> P2[Alert went to a rotation nobody watched]
  M --> M1[No load test before release]
  M --> M2[Change approved without rollback plan]
  T --> T1[Payment provider timeout not handled]
  T --> T2[Retry storm from client]
  D --> D1[Stale feature flag config]

#A few things that catch people out

• Agree the categories first, or every cause lands in whichever branch was drawn first.

• Keep asking why within a branch; the first cause listed is rarely the root.

• Causes are not actions. Turn the diagram into actions afterwards, separately.

#Related

Generate first. Organise second.