Retro format 22 of 27
Fishbone retrospective
Put the problem at the head of a fish and list causes along bones: code, process, tools, people, requirements, environment.
- 45–50 min
- 2 to 10 people
- Works remote
Good for
A problem with many causes, like a slow CI pipeline or a run of production bugs. It stops the team fixing only the first cause it finds.
Also called: Ishikawa diagram
Facilitator tip
Circle only the causes you have evidence for. A fishbone full of guesses fixes the wrong thing.
The Fishbone board, drawn out.
6 areas: Code, Process, Tools and infra, Knowledge, Requirements, Environment. Draw the picture on your whiteboard before the retro. Here's what a software team might put in each.
1Code
No contract tests between services
2Process
Reviews skip the migration files
3Tools and infra
Staging data is six months old
4Knowledge
Only one person knows the billing rules
5Requirements
Edge cases missing from tickets
6Environment
Prod runs a different Redis version
How to run a Fishbone retrospective.
About 50 minutes as written. Change the length in the agenda builder below and every step scales with it.
- 1
Check in
5 min
Say why you're here and that the retro is about the system, not people. Go through last retro's action items: done, in progress, or dropped on purpose.
- 2
Write the problem
3 min
State the effect at the head: 'Three bugs reached production this sprint'.
- 3
Add causes to the bones
12 min
Everyone adds causes under each category. Ask why for each to add smaller bones.
- 4
Circle the likely causes
8 min
Everyone gets three votes for the causes most likely to matter.
- 5
Check the top causes
7 min
For each circled cause: do we have evidence? How would we check?
- 6
Agree action items
10 min
Pick one to three actions from the top topics. Each gets one owner and a due date, and goes into the next sprint's backlog, not only the retro notes.
- 7
Close
5 min
Read the actions and owners back. Ask everyone to rate the retro 1 to 5 (return on time invested) and change one thing next time if the scores are low.
Prompts to put on the board.
Read one out when the writing stalls, or paste them next to the columns.
- What in the code made this likely?
- What in our process let it through?
- Which tool or environment played a part?
- What did someone not know that they needed to?
Your Fishbone agenda, timed to your slot.
Fill in the team and the time. Copy the agenda into Confluence, Notion or Google Docs as formatted text, or grab the Markdown.
Length
- 0:00–0:05Check in · 5 min
- 0:05–0:08Write the problem · 3 min
- 0:08–0:20Add causes to the bones · 12 min
- 0:20–0:28Circle the likely causes · 8 min
- 0:28–0:35Check the top causes · 7 min
- 0:35–0:45Agree action items · 10 min
- 0:45–0:50Close · 5 min
Payments team Sprint 14 retro: Fishbone
Length: 50 min
Put the problem at the head of a fish and list causes along bones: code, process, tools, people, requirements, environment. A problem with many causes, like a slow CI pipeline or a run of production bugs. It stops the team fixing only the first cause it finds.
Agenda
| Time | Step | Min |
|---|---|---|
| 0:00–0:05 | Check in | 5 |
| 0:05–0:08 | Write the problem | 3 |
| 0:08–0:20 | Add causes to the bones | 12 |
| 0:20–0:28 | Circle the likely causes | 8 |
| 0:28–0:35 | Check the top causes | 7 |
| 0:35–0:45 | Agree action items | 10 |
| 0:45–0:50 | Close | 5 |
How to run each step
- Check in (5 min). Say why you're here and that the retro is about the system, not people. Go through last retro's action items: done, in progress, or dropped on purpose.
- Write the problem (3 min). State the effect at the head: 'Three bugs reached production this sprint'.
- Add causes to the bones (12 min). Everyone adds causes under each category. Ask why for each to add smaller bones.
- Circle the likely causes (8 min). Everyone gets three votes for the causes most likely to matter.
- Check the top causes (7 min). For each circled cause: do we have evidence? How would we check?
- Agree action items (10 min). Pick one to three actions from the top topics. Each gets one owner and a due date, and goes into the next sprint's backlog, not only the retro notes.
- Close (5 min). Read the actions and owners back. Ask everyone to rate the retro 1 to 5 (return on time invested) and change one thing next time if the scores are low.
Board
- Code
- Process
- Tools and infra
- Knowledge
- Requirements
- Environment
Prompts
- What in the code made this likely?
- What in our process let it through?
- Which tool or environment played a part?
- What did someone not know that they needed to?
Last retro's action items
| Action | Owner | Status |
|---|---|---|
Action items
| Action | Owner | Due |
|---|---|---|
Copy pastes as formatted text into Google Docs, Notion or Confluence. Markdown is for GitHub, Jira or Slack.
Try next, when this one gets stale.
- 11
Three Little Pigs
- 45–57 min
- 2 to 20
- Great remote
- 15
Five Whys
- 45–55 min
- 2 to 10
- Works remote
- 16
Futurespective
- 45–60 min
- 2 to 20
- Great remote
Book the retro on a day the whole team is in.
A retro with two people out hears half the sprint, and its actions have no owners. Forgot shows sprints, holidays and time off on one board, so you can see who's out on retro day before you send the invite.
Fishbone retrospective questions
What is a Fishbone retrospective?
Put the problem at the head of a fish and list causes along bones: code, process, tools, people, requirements, environment. A problem with many causes, like a slow CI pipeline or a run of production bugs. It stops the team fixing only the first cause it finds.
How long does a Fishbone retro take?
45 minutes at the shortest, and about 50 minutes as written here. The agenda builder on this page stretches or squeezes each step to fit your slot.
Can you run Fishbone remotely?
Yes, with some prep. Draw the board on a shared whiteboard before the call, and give people a few extra minutes for each step, since it needs more back-and-forth than a column retro.
What goes on a Fishbone board?
6 areas: Code, Process, Tools and infra, Knowledge, Requirements, Environment. For example, from a software team: Code: “No contract tests between services”; Process: “Reviews skip the migration files”; Tools and infra: “Staging data is six months old”; Knowledge: “Only one person knows the billing rules”; Requirements: “Edge cases missing from tickets”; Environment: “Prod runs a different Redis version”.
What team size is Fishbone for?
2 to 10 people. With more people, split into groups for the writing and discussion, then bring the top topics back together.
What can I run instead of Fishbone?
Three Little Pigs, Five Whys, Futurespective. They suit similar sprints from a different angle. Rotate formats every two to four sprints so the retro doesn't go stale.