Fishbone Retrospective Template (Ishikawa Diagram)

A fishbone retrospective lays out every possible cause of one problem, sorted into categories, before anyone decides which cause is real. The problem is the fish's head and the causes are its bones. Retro Rabbit's board has five bones: People, Process, Tools, Environment and Measurement. Use it when a problem has too many suspects for one line of questioning.

The five columns

How the board maps to the classic diagram. On paper, the problem is the head and each category is a bone, with smaller bones for sub-causes. Manufacturing versions often use six Ms: manpower, methods, machines, materials, measurement and mother nature. The board fits them into five columns: People is manpower, Process is methods, Tools covers machines and materials, Environment is mother nature, and Measurement stays. The head becomes the retro's name, and sub-causes become groups of notes within a column.

Where it comes from. The Japanese quality engineer Kaoru Ishikawa invented the cause-and-effect diagram, which is why it's also called the Ishikawa diagram (JUSE, the Union of Japanese Scientists and Engineers). He taught it as one of the basic quality tools in his Guide to Quality Control, which the Asian Productivity Organization published in English in the 1970s. The fishbone name comes from its shape.

When to use it (and when not to)

Use it when:

• a problem has many suspects and people argue for their favorite: flaky builds, a slow page, missed sprint goals
• the same problem came back after a 5 Whys fixed one cause
• you want quieter people's theories on the board before the loudest one wins

Pick something else when:

• the cause is fairly clear and you need to go deep, not wide. Use 5 Whys.
• it was one outage with a timeline. Start with an incident review.
• the problem is a feeling, like "morale is low". A fishbone needs a head you can measure. Try Mad Sad Glad.

How to run it live (45 minutes)

1. Carry-over, then the head. Check Previous Retro and Old / Unresolved Items in the Action Items panel. Then read the problem out loud. It should be measurable: "Main build fails about one run in four since September," not "CI is bad."
2. Write silently, one cause per note. Set the shared timer for 12 minutes and ask everyone to consider every column.
3. Group within columns. Drag notes that describe the same cause onto each other. Each group is a sub-bone.
4. Vote for likeliest, not loudest. Dot voting, three votes each, then sort by Most Votes.
5. Ask for evidence. For each of the top three: do we know this, or suspect it? Most fishbone causes are hypotheses. A suspected cause gets a check first; a confirmed one gets a fix.

How to run it async over a sprint

Fishbone suits async, because causes occur to people at odd moments: during a rerun, in code review, on call.

1. Day 1: start the retro with Fishbone (Try a different format in Start New Retro) and post the baseline in Measurement: "Main build failure rate: 24% over the last 30 days."
2. During the sprint: whoever hits the problem adds a possible cause, with a link or log line if they have one, on the board or through Quick Notes.
3. Mid-sprint: the facilitator asks one person per empty column for a note. Environment and Measurement are the usual gaps.
4. Two days before the end: everyone votes. The facilitator groups duplicates and reads the CarrotIQ summary of each column.
5. Retro day: a 20-minute call on the top three causes and their checks. Or post the top three with a proposed check each, and let owners accept in writing.

See how to run an async retrospective.

10 example prompts

People

1. Who is the only person who knows how this works?
2. Did anyone new or overloaded work in this area recently?

Process 3. Which step do we skip when we're in a hurry? 4. What do we do when this problem happens, and does that make it worse?

Tools 5. Which part of the code or infrastructure is oldest or least tested? 6. What changed in our dependencies just before this started?

Environment 7. What do we share with other teams that could interfere? 8. Does it follow a pattern in time: end of day, release week, one time zone?

Measurement 9. Could our numbers be hiding or exaggerating the problem? 10. What would we need to measure to prove a cause?

For more, see 60 sprint retrospective questions.

Facilitator tip and a common pitfall

Tip: put each note where its fix would live. "Nobody owns CI health" could be People or Process. If the fix is naming an owner, it's Process. It also stops one cause appearing in three columns.

Pitfall: treating votes as proof. Voting tells you which causes the team believes, not which are true. Teams that fix the top-voted cause straight away often find the problem still there a sprint later. Make the first action item a check that confirms or rules out the cause.

How AI helps with this format

On Pro AI (and during the free trial), CarrotIQ handles the admin around the board:

• Group names. Drag "fixed sleeps in E2E" onto "tests depend on timing" and CarrotIQ names the sub-bone, for example "Timing-Dependent Tests".
• Summaries. The Sprint Summary covers each column, a quick way to see which bone carries the most weight, plus the whole retro.
• Suggested action items. CarrotIQ Suggest drafts an action weighted by the most-voted causes. If a cause isn't confirmed, edit the draft into a check.

Example action items

At the next retro, compare the failure rate with the number in the head. See retrospective action items that actually get done.

Use this template in Retro Rabbit

1. Start a 14-day free trial. No card is needed.
2. For one retro, click Try a different format in Start New Retro and pick Fishbone: it applies to that retro only, and your Team Room keeps its usual columns. To make it the room's format, choose it under "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
3. In the same dialog, type the problem as the retro's name, then post today's number in Measurement so you can see later whether it moved.

Want other bones, such as Policies or Customers? With Fishbone as the room's format, rename the columns in the Team Room's Settings. See pricing for plans.

Related formats

• 5 Whys: dig deep into the cause the vote picked
• Incident Review: when the problem is one outage with a timeline
• Project Post-Mortem: a whole project, root causes included
• Kanban retrospective: when the problem is flow: waiting, WIP and blocked work
• More formats in Incidents and postmortems
• All retrospective templates