Symptoms

What pains did you have in the last sprint?

Our daily standups regularly exceed 20 minutes, making us lose focus
We're constantly context switching between three different projects
Technical debt is slowing down our feature delivery
Diagnosis

What could be the root causes?

Lack of clear acceptance criteria is causing confusion and delays
Team capacity isn't accurately considered during sprint planning
Missing documentation guidelines make it unclear what needs to be documented
Treatment

How can we treat or manage this?

Implement a 15-minute timer for daily standups
Create a dedicated tech debt story in each sprint
Schedule weekly sync meetings between frontend and backend teams
Follow Up

How can we track progress and improvement?

Review standup duration metrics weekly
Track number of bugs reported per sprint
Measure story point completion rate trends
Prevention

What can we do to stay well?

Schedule regular knowledge sharing sessions
Implement pair programming for complex features
Set up automated code quality checks

What is the Sprint Clinic Retrospective?

The Sprint Clinic retrospective runs your retro like a visit to the doctor. Your team lists the symptoms it felt during the sprint, works out what's causing them, and agrees on a treatment, a follow-up and some prevention so the same problems don't come back. The board has five columns, in the order a consultation runs. Symptoms is where people describe the pains: long standups, constant context switching, rework. Diagnosis digs into root causes, often with a quick round of 5 Whys. Treatment holds the practical fixes. Follow Up sets how you'll check the fix worked, and Prevention covers the habits that keep the team healthy. Splitting the symptom from the diagnosis stops the team from jumping straight to a fix for the wrong problem. Use it after a rough sprint, or when the same issues keep showing up retro after retro and you want to get underneath them.

Sprint Clinic retrospective format

Symptoms

What pains did you have in the last sprint?

Ask the team to name specific issues that affected the sprint, not vague complaints. Think of it as taking a patient history: the more specific the symptom, the better the diagnosis.

Diagnosis

What could be the root causes?

Take each symptom and dig for the cause. A quick round of 5 Whys works well here. Keep the focus on how the work is set up, not on individuals.

Treatment

How can we treat or manage this?

Ask for fixes the team can actually put in place. Check that each treatment matches a diagnosis, and rank them by impact and effort before you commit.

Follow Up

How can we track progress and improvement?

Decide how you'll know the treatment worked. Pick a simple measure or checkpoint for each fix and set a date to review it, like booking a follow-up appointment.

Prevention

What can we do to stay well?

Prevention is about habits that stop problems coming back. Look for small practices the team can keep up as part of its routine, not one-off fixes.

When to use this retrospective

  • When the same issues keep coming back and you want to find out what's causing them
  • After a rough sprint where several problems need attention at once
  • When your retros tend to jump straight to fixes without agreeing on the cause
  • When the team needs both quick fixes and longer-term habits

Suggested icebreaker questions

  • If your last sprint was a patient, what would its health be on a scale of 1 to 10?
  • What's your favorite home remedy for fixing a broken process?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Keep the medical theme light. It's there to give the discussion an order, not to make the session feel clinical
  • Ask everyone to add to every column, since different people notice different symptoms and suggest different fixes
  • Use Prevention for habits the team will keep, not one-off fixes
  • Give every agreed action an owner so someone follows it through
  • Track the Follow Up measures over a few sprints so you can see whether the treatment is working
  • Keep the diagnosis on how the work is set up, not on individual performance

Frequently asked questions

What is a Sprint Clinic retrospective?
It's a retrospective that borrows the steps of a doctor's visit. Your team lists the sprint's symptoms, diagnoses root causes, prescribes treatments, plans a follow-up and agrees on prevention habits.
What columns does the Sprint Clinic retrospective use?
Five: Symptoms (the pains you felt), Diagnosis (root causes), Treatment (practical fixes), Follow Up (how you'll check the fix worked) and Prevention (habits that stop the problem coming back).
When should we use the Sprint Clinic retrospective format?
Use it after a rough sprint with several problems, or when the same issues keep coming back. It suits teams that tend to jump to fixes before agreeing on the cause.
How long does a Sprint Clinic retrospective take?
Plan for about 60 to 75 minutes, since there are five columns. If time is short, take only the top two or three symptoms through diagnosis and treatment.
How is it different from a root cause analysis like 5 Whys or fishbone?
Those techniques stop at the cause. Sprint Clinic uses a quick root cause step inside a wider flow that also covers the fix, how you'll check it worked and how to prevent a repeat.
Ready to run this retrospective?Try this retrospective live