The fishbone diagram (also called an Ishikawa or cause-and-effect diagram) organizes potential causes into six categories and connects them to a single effect. Draw it on a whiteboard, fill the bones, snap it, and find the fix.
Use a fishbone diagram when a problem has multiple potential causes across different domains — process, people, tools, environment — and you need to analyze them in parallel rather than in a single causal chain.
Fishbones are standard in quality management (manufacturing, healthcare, product reliability) but work equally well for software incidents, customer churn analysis, and service failures. The structure is most useful when a team has competing theories about what's causing a problem.
The problem or effect you're analyzing, written at the right end of the spine. Be specific and observable: 'sprint deployments fail more than twice per week' not 'deployments are unreliable.' The effect is the symptom you're trying to explain.
Causes related to the humans involved: insufficient training, unclear ownership, communication gaps, cognitive overload, skill mismatches. Ask: which people-related factors could be contributing to this effect?
Causes related to the steps, workflows, and procedures: missing review steps, unclear handoffs, no standard operating procedure, inconsistent execution. The process bone often reveals that the problem isn't a people problem — it's a process problem.
Causes related to the technology, machines, and tools: outdated software, missing tooling, unreliable infrastructure, wrong tool for the job. In software teams, this often covers CI/CD pipeline issues, IDE configurations, and monitoring gaps.
Causes related to the context in which work happens: working conditions, distractions, remote vs. in-person, physical space, time pressure, organizational culture. Environment causes are often overlooked and hard to change — but naming them is the first step.
Causes related to the raw inputs: unclear requirements, missing data, poor documentation, inconsistent specs. In a manufacturing context, this is literal materials. In a software context, it's requirements, data quality, and design artifacts.
Causes related to how the process is measured: wrong metrics, infrequent monitoring, measurement lag, no feedback loop. If you're not measuring the right things, you can't see the problem building until it's already a failure.
Draw a horizontal line (the spine) pointing to the right. Write the effect in a box at the right end (the fish head). Draw six diagonal bones off the spine — three up and three down — and label each with a cause category.
Work through each bone category. Ask 'what in this category could be causing the effect?' Write one cause per sticky and post it on the appropriate bone. Quantity first — get everything on the board before evaluating.
For the most populated bones, ask why that cause exists. Add sub-cause branches off the main bone. These are the second-level causes that lead to the primary cause.
Each team member gets three dot votes. Identify the causes most likely to be driving the effect. The highest-voted items become the investigation priorities.
Define a hypothesis test for each top-voted cause: 'If this is the cause, we'll see X.' Assign an owner. Snap the diagram with BoardSnap — the AI reads the bone structure and outputs the investigation priorities as action items.
A fishbone diagram is inherently spatial — the six bone categories spread out from the spine in a way that shows category balance at a glance. If three bones are full and three are empty, that tells you something about where the team's theory of the problem is concentrated. Digital tools flatten that signal. A physical whiteboard preserves it.
BoardSnap reads the diagram structure — spine, bones, and sub-branches — and outputs a structured cause inventory with vote tallies and investigation priorities. The visual becomes actionable without re-entering the content into another tool.
The classic six are: Man (People), Machine (Equipment), Method (Process), Material (Inputs), Measurement, and Environment — sometimes called the '6 Ms.' For service industries or software teams, the categories are often adapted: People, Process, Technology, Environment, Materials/Inputs, and Measurement. Use the categories that fit your context.
The five whys follows a single causal chain — one 'because' after another. The fishbone analyzes multiple potential causes in parallel, organized by category. Use five whys when you have one obvious causal chain. Use the fishbone when you have multiple competing theories or a complex problem with causes across different domains.
Four to eight people, with at least one representative from each domain relevant to the problem. Too few and you miss perspectives; too many and the session becomes unwieldy. For a software incident, include engineering, QA, DevOps, and product.
During the session, while context is fresh. Post-session voting loses the discussion context — people vote on the label, not on the argument made in the room. Run the dot vote at the end of the brainstorm phase, before anyone leaves.
No exporting, no transcription. Snap the board, get the action plan.