Fishbone Diagram: Categories, Steps, and Examples

A fishbone diagram, also called an Ishikawa diagram or cause-and-effect diagram, is a visual tool for finding the causes behind a problem. You write the effect at the head of the fish, draw a horizontal spine, and branch off the possible causes as bones grouped into categories. Instead of guessing at one obvious culprit, a fishbone diagram spreads every candidate cause across the page so a team can see them all at once.

The tool sits in the same family as a Mermaid diagram for sketching logic and a data flow diagram for mapping systems: artifacts that turn a fuzzy idea into something a group can point at and argue about. Where those show structure, a fishbone diagram answers a different question. When something went wrong, what could have caused it, and which cause is worth chasing first?

This guide covers what a fishbone diagram is, its anatomy, the 6M categories and the service variant, how to build one in six steps, how it pairs with the 5 Whys, worked examples for a software bug and a churn problem, when the tool helps and when it does not, and how to keep the root cause analysis it produces in your team's process documentation.

What is a fishbone diagram?

A fishbone diagram is a cause-and-effect diagram that organizes the possible causes of a problem into categories, so a team can brainstorm systematically instead of fixating on the first explanation. The name comes from its shape: a central spine with branches that look like the skeleton of a fish. The problem sits at the head, and the causes fan out along the bones.

Kaoru Ishikawa, a Japanese quality control expert, developed the tool at the University of Tokyo in the 1960s, which is why it carries his name. It became one of the "seven basic tools of quality" recognized by the American Society for Quality, alongside the Pareto chart and control chart. Decades later, teams still reach for it during root cause analysis, quality reviews, and post-incident retrospectives.

The value is structure. Faced with a defect or a failure, people tend to latch onto a single familiar cause. A fishbone diagram forces the group to consider several categories of cause before settling on one, which surfaces contributing factors that a quick discussion would miss. It is a brainstorming tool first and a diagram second.

Anatomy of a fishbone diagram

Every fishbone diagram has three structural parts. Once you can name them, reading or drawing one becomes straightforward.

• The head (effect). A box on the right holds the problem statement, the effect you want to explain. Write it as a specific, measurable symptom: "Checkout error rate up 12% this week," not "checkout is broken."
• The spine. A single horizontal arrow runs from left to right into the head. It is the backbone that every category branch connects to.
• The bones (causes). Diagonal branches off the spine are the major cause categories. Smaller sub-bones branch off each category to hold specific causes and sub-causes, going as deep as the analysis needs.

The layout matters because it keeps related causes together. All the equipment causes cluster on one bone, all the process causes on another. When the diagram is done, a reader can scan one category at a time rather than wading through a flat list. That grouping is exactly what a plain brainstorm on a whiteboard lacks.

The 6M categories (and the service variant)

The bones need labels, and most teams start from a standard set of categories rather than inventing them each time. Manufacturing and engineering teams use the 6Ms. Service and software teams often swap in the 6Ps, sometimes called the 4S or 8P depending on the source. The categories are prompts, not rules. Use the ones that fit your problem.

The 6Ms map cleanly to a factory: a person operates a machine using a method on some material, checked by measurement, all inside an environment. The service version keeps the same idea while renaming bones to match how a team that ships software or runs a service actually talks. Some people call the five core manufacturing bones the "5 M's": Man, Machine, Method, Material, and Measurement, with Mother Nature added as the sixth.

Neither list is sacred. If a category produces no causes for your problem, drop it. If your problem needs a bone the standard set does not cover, such as "Data quality" or "Vendor," add it. The goal is complete coverage of where causes might hide, not fidelity to a template.

How to create a fishbone diagram

Building a fishbone diagram works the same on a whiteboard, a sticky-note wall, or in software. Follow these steps in order.

1. State the problem precisely. Write the effect in the head box. Make it specific and measurable so the team analyzes one thing, not a vague complaint. A sharp problem statement is half the work.
2. Draw the spine and head. Put the problem box on the right and draw the horizontal arrow pointing into it. This is your canvas.
3. Add the category bones. Branch the main categories off the spine. Start from the 6Ms or 6Ps, then trim or rename to fit. Four to six bones is typical.
4. Brainstorm causes onto each bone. For every category, ask what within it could produce the effect. Write each cause as a sub-bone. Encourage the group to fill every category before judging any answer.
5. Drill into sub-causes. For each cause, ask "why does that happen?" and branch the answer as a deeper sub-bone. This is where the 5 Whys technique connects, covered next.
6. Analyze and prioritize. Step back and look for causes that appear in more than one category, or that the team keeps circling back to. Mark the two or three most likely root causes to investigate with data.

A common mistake is stopping at step four and treating the full diagram as the answer. It is not. The diagram lists candidate causes; it does not prove any of them. The last step, verifying the likely causes against real data, is what turns a brainstorm into root cause analysis.

Fishbone diagram and the 5 Whys

The fishbone diagram and the 5 Whys are complementary, and pairing them is one of the most useful moves in root cause work. The fishbone spreads causes wide across categories. The 5 Whys drills one cause deep. Used together, you get both breadth and depth.

Here is the flow. Build the fishbone to surface every plausible cause. Pick the most likely bone. Then run the 5 Whys on it: ask "why?" about the cause, then "why?" about that answer, roughly five times, until you reach a cause you can actually fix. The fishbone tells you where to point the 5 Whys, and the 5 Whys turns a surface symptom on a bone into an underlying root cause.

For example, a fishbone might list "deploy script failed" under the Method bone. Asking why five times could walk you from "the script failed" to "it timed out" to "the database migration was slow" to "an index was missing" to "the migration review skipped index checks." That last answer is a root cause you can prevent. The bone found the thread; the 5 Whys pulled it.

Fishbone diagram examples

Two short walkthroughs show how the tool works on real problems, one technical and one business.

Example 1: a software bug. The effect is "Users intermittently logged out mid-session." A team brands the bones People, Platform, Process, and Data. Under Platform: "session token expiry too short," "load balancer drops sticky sessions." Under Process: "no alerting on auth errors," "hotfix skipped staging." Under Data: "session store evicting keys under memory pressure." Under People: "on-call unfamiliar with the auth service." Scanning the diagram, "session store evicting keys" and "token expiry too short" both point at session lifetime, so the team investigates those two first and confirms the eviction with metrics.

Example 2: customer churn. The effect is "Monthly churn rose from 3% to 5%." Bones: People, Product, Process, Price. Under Product: "onboarding drop-off," "missing integration competitors have." Under Process: "slow support response," "no proactive check-ins." Under Price: "recent plan increase," "no annual discount." Under People: "reduced customer success headcount." The team notices "onboarding drop-off" and "reduced customer success headcount" reinforce each other, prioritizes onboarding, and validates it against funnel data before committing to a fix.

Both examples end the same way: the diagram narrows a wide field of causes to a short list worth testing. It never hands you the answer outright, and treating it as if it does is the fastest way to fix the wrong thing.

Sketching a fishbone as a Mermaid diagram

Mermaid, the text-based diagramming syntax that Docsio renders live, has no native fishbone chart. You can approximate the spine-and-bones structure with a mindmap, where the central node is the effect and each branch is a cause category. It reads top-down rather than left-to-right, but the grouping is identical.

mindmap
  root((Users logged out mid-session))
    People
      On-call unfamiliar with auth service
    Platform
      Token expiry too short
      Load balancer drops sticky sessions
    Process
      No alerting on auth errors
      Hotfix skipped staging
    Data
      Session store evicting keys

Because Mermaid lives as plain text, this version can sit inside a version-controlled document and update alongside the investigation, unlike a diagram exported as a flat image.

When to use a fishbone diagram (and when not to)

A fishbone diagram earns its place when a problem has many possible causes and the team disagrees, or has not yet thought broadly. It shines in quality reviews, manufacturing defect analysis, incident retrospectives, and any situation where jumping to the first cause would be a mistake. It is also a strong facilitation tool, since giving people named categories makes a group brainstorm far more productive than an open discussion.

It is the wrong tool in a few cases. If the cause is already obvious and confirmed, skip the diagram and fix the problem. If the problem is a linear sequence of steps, a flowchart or process map fits better. And the fishbone does not quantify anything: it shows which causes exist, not how much each contributes. For that, pair it with a Pareto chart or with data analysis. The diagram generates hypotheses; it does not test them.

One more limit worth naming. A fishbone can grow into a sprawling wall of bones that lists everything and prioritizes nothing. Keep the categories tight, cap the depth, and always finish with the prioritization step. A diagram that names three likely root causes beats one that names thirty possible ones.

Documenting root cause analysis

A fishbone diagram is a thinking tool, and thinking tools have a short shelf life if the output vanishes when the whiteboard gets wiped. The diagram itself is disposable. The root cause analysis it produces is not. That analysis belongs in a living document your team can find months later, when the same class of problem shows up again.

This is where the fishbone connects to your written records. The causes you confirmed, the root cause you fixed, and the diagram that got you there are all part of a post-mortem or an incident write-up. Keeping them together means the next person who hits a similar failure starts from your analysis instead of a blank page. A fishbone diagram lost in a photo of a whiteboard helps no one; the same diagram embedded in a searchable doc becomes institutional knowledge.

Docsio is not a diagramming tool, and it will not draw the fishbone for you. What it does is turn your notes and existing pages into a branded documentation site that renders Mermaid diagrams inline, so the cause-and-effect sketch and the RCA write-up live on the same page rather than in separate tools. Its AI documentation generation can draft the surrounding incident or quality pages from your notes, leaving you to drop the analysis into context. If you run retrospectives, the natural next step is a repeatable post-mortem template that gives every fishbone a home.

Conclusion

A fishbone diagram turns a hard question, "what caused this?", into a structured search instead of a guess. Put the effect at the head, branch the causes into categories like the 6Ms or 6Ps, brainstorm each bone, then use the 5 Whys to drill the most likely cause down to something you can fix. The diagram's job is to widen your view of possible causes; your job is to verify the short list against data. Do both, write the result somewhere your team will find it, and one afternoon of diagramming prevents the same problem from recurring for years.

Frequently asked questions

What is a fishbone diagram used for?

A fishbone diagram is used to identify and organize the possible causes of a problem during root cause analysis. Teams use it in quality reviews, defect investigations, and incident retrospectives to brainstorm causes across categories, so they consider several explanations instead of fixating on the first one that comes to mind.

What is the 5 Whys fishbone diagram?

It is the practice of pairing two root cause tools. The fishbone diagram spreads possible causes wide across categories, while the 5 Whys drills one cause deep by asking "why?" about five times. You build the fishbone to find likely causes, then run the 5 Whys on the strongest bone to reach the underlying root cause.

What are the 5 M's of fishbone analysis?

The 5 M's are the core cause categories used in manufacturing fishbone diagrams: Man (people), Machine (equipment), Method (process), Material (inputs), and Measurement (metrics). Adding Mother Nature, the surrounding environment, makes the well-known 6M set. Each category prompts the team to check a different place where causes might hide.

What are the 5 steps for creating a fishbone diagram?

State the problem precisely in the head box, draw the spine and head, add the main category bones such as the 6Ms, brainstorm specific causes onto each bone, then analyze the diagram to prioritize the most likely root causes for verification. Drilling into sub-causes with the 5 Whys sits between brainstorming and analysis.