Fishbone Analysis Retrospective Template

Also known as the Ishikawa diagram, this format helps the team trace a problem back to its root causes. Possible causes are grouped across categories like people, process, tools, program and environment before the team converges on solutions. It's a methodical choice when a recurring issue needs a structured investigation rather than a quick fix.

People

Causes rooted in skills, staffing or knowledge held by one person

Roman

Only one person knows the deploy path for billing

Maria

New hires shadow for a week, then are on their own

Process

Causes in how the team works: steps skipped, rules unwritten

Anna

No rollback rehearsal since the pipeline changed

Daria

Hotfixes skip review when someone calls it urgent

Tools

Causes in tooling: gaps in alerts, tests, environments

Maria

Alerting does not cover payment failure rate

Kirill

Staging data does not match production shapes

Program

Causes in planning: scope, funding, deadlines

Daria

The migration was planned for four days and funded for two

Roman

Scope grew after planning with no date change

Environment

Causes outside the team: vendors, traffic, org changes

Kirill

Peak season traffic is twice last year

Anna

The vendor deprecated the API version we depend on

Solutions

Fixes that address the causes above, with an owner

Roman

Add payment-failure alerting and a weekly rollback drill

Maria

Second maintainer for billing by end of quarter

Try Template

What is the Fishbone (Ishikawa) Analysis retrospective?

The Fishbone, or Ishikawa, retrospective is built for root cause analysis. Instead of fixing symptoms, the team traces a problem back to its real sources by examining it across several categories. The structure stops the discussion from circling one obvious culprit and pushes it toward the underlying causes.

People — skills, communication, roles
Process — workflows and ways of working
Tools — software, infrastructure, tooling
Program — planning, scope, requirements
Environment — context and external factors
Solutions — fixes for the causes found

People

This category explores the human side: missing skills, unclear roles, communication gaps or handover issues that may have contributed to the problem.

Process

Here the team examines how work flows. Bottlenecks, unclear steps, missing checks or heavy handoffs often hide the deeper cause behind a recurring issue.

Tools

Tools covers software, infrastructure and tooling. Flaky pipelines, missing automation or the wrong tool for the job can quietly create repeated failures.

Program

This category looks at planning, scope and requirements. Unclear goals, shifting scope or poor estimates frequently sit at the root of delivery problems.

Environment

Environment captures the surrounding context: external dependencies, organisational pressure or conditions the team can't fully control but must account for.

Solutions

Once causes are mapped, Solutions turns analysis into action — concrete fixes aimed at the real roots rather than the surface symptoms.

Benefits of the Fishbone (Ishikawa) Analysis retrospective

Drives the team past symptoms to true root causes
Organises a messy problem into clear categories
Prevents blame by spreading the lens widely
Makes recurring issues visible and addressable
Connects analysis directly to concrete solutions
Suits incident reviews and deep problem-solving

How to run a Fishbone (Ishikawa) Analysis retrospective

Create a board in QRetro from the Fishbone (Ishikawa) Analysis template.
State the problem clearly so everyone shares the same focus.
Brainstorm possible causes within each category.
Ask "why" repeatedly to dig from symptoms to root causes.
Highlight the most likely causes together.
Capture targeted solutions with owners in the Solutions column.

Similar templates

Other formats teams pair with this one — open any of them as a board in one click.

WRAP Retrospective

WRAP gathers four kinds of input that together give a rounded view of the sprint. The team shares its wishes, voices appreciations, names the risks it sees and surfaces the things that still puzzle it. Mixing gratitude with concern keeps the conversation both supportive and honest.

Learning Matrix

A four-quadrant format that captures feelings, ideas and gratitude in one view. The team notes what made it smile, what disappointed it, the new ideas worth trying and the appreciations it wants to share. The balanced layout makes it easy to leave the session with both improvements and a sense of recognition.

RAID Log Analysis

A project-management format that puts the spotlight on what could derail delivery. The team logs its risks, the assumptions it's relying on, the issues already in play and the dependencies on other teams or systems. Reviewing all four regularly keeps surprises to a minimum and makes planning conversations far more grounded.

Liked - Lacked - Change Retrospective Template

A reflective format that moves from observation straight to ownership of change. The team names what it liked and what it lacked, then splits change into two columns — what each person can do differently and what the team can change together. Separating personal and collective action makes the resulting commitments clearer and more actionable.

Time: Added Stolen Restored

A reflective format that examines how the team and its members spend their most limited resource — time. Participants look at the choices that add time to the day, the habits that steal it and the ways to reclaim what's been lost. It's a personal, mindful angle on productivity that goes beyond process and into working habits.

Appreciation Retro

A retrospective built around continuous improvement and an empathetic team culture. Alongside the usual reflection on what was good and what fell short, it makes space to wonder, to commit to action items and, above all, to appreciate one another. The strong emphasis on gratitude helps teams ask hard questions without fear and have courageous conversations.

Try Template