Squad health check: what it is and how to run it with your team
A squad health check is a conversation in which a team rates its own health on ten topics, such as ease of release, tech quality and fun. Each person gives every topic a color (green, yellow or red) and says whether it is improving or getting worse. The result shows, on one screen, where the team is doing well and what to improve first. On this page: the ten indicators with examples, a step-by-step guide, how to read the results and the mistakes that get in the way.
Squad Reviews brings your tech team's tools together in one place. The first is the live retrospective, where the team turns what the health check showed into action items with an owner.
Sign in with Google, Slack or a sign-in link sent to your e-mail. No password.
Only your company's members see its retrospectives.
What is a squad health check?
The Squad Health Check is a self-assessment model for tech teams. Henrik Kniberg and Kristian Lindwall created it at Spotify and published it in 2014. The idea is simple: the team talks through a set of topics and, for each one, decides whether it is closer to the ideal picture or to the bad one.
It does not measure performance and it is not a team score. It helps the team see what to improve, and it helps the people who lead the team see where they can help. The authors say the model works only where there is trust: if results are used to judge or compare teams, people start hiding their problems.
Based on the Squad Health Check model by Henrik Kniberg and Kristian Lindwall (Spotify, 2014).
What are the 10 squad health check indicators?
Each indicator has two ends: what it looks like when things go well and when they go badly. The team decides which end it is closer to today. The original model suggests about ten topics, and the team is free to change, drop or add any of them.
Easy to release
- When it goes well
- Releasing is simple, safe and mostly automated.
- When it goes badly
- Every release is risky, full of manual steps and takes days.
Suitable process
- When it goes well
- Our way of working fits the team.
- When it goes badly
- Our process gets in the way more than it helps.
Tech quality
- When it goes well
- We are proud of our code: clean, easy to read and well tested.
- When it goes badly
- The code is hard to change and technical debt keeps growing.
Value
- When it goes well
- We ship good things, we are proud of them and the people who use them are happy.
- When it goes badly
- What we ship does not solve the problem, and our users notice.
Speed
- When it goes well
- Work moves fast, with no waiting and no blockers.
- When it goes badly
- Nothing gets finished: everything stalls on dependencies and interruptions.
Mission
- When it goes well
- We know why the team exists, and it motivates us.
- When it goes badly
- We do not know why we are here or where we are going.
Fun
- When it goes well
- We enjoy working together, and the days feel light.
- When it goes badly
- Work is dull and everyone is waiting for the day to end.
Learning
- When it goes well
- We learn new things all the time.
- When it goes badly
- There is never time to learn anything.
Support
- When it goes well
- When we ask for help, it arrives quickly.
- When it goes badly
- We get stuck because the help we ask for never comes.
Pawns or players
- When it goes well
- The team decides what to build and how to build it.
- When it goes badly
- We are pieces in someone else's game, with no say in what we do.
The example statements on this page are our adaptation of the original cards, under CC BY-SA 4.0 (see the attribution at the end of the page).
What do the colors and the trend mean?
For each indicator, each person answers two things: how it is today (the color) and where it is heading (the trend). The color always comes with its name written out, so nobody has to rely on color alone.
Green, yellow and red
- Green: the team is happy with this topic and sees no urgent need to change it. It does not mean perfect.
- Yellow: there are problems worth attention, but it is not an emergency.
- Red: this topic is in bad shape and needs to improve.
Trend: improving, stable or getting worse
- Improving: better than last round.
- Stable: unchanged.
- Getting worse: worse than last round.
The trend often says more than the color. A yellow that is improving is good news; a green that is getting worse needs a conversation before it turns yellow.
How to run a squad health check, step by step
Prepare the session
Book one to two hours with the whole team and someone to facilitate, ideally a person outside the team's daily work, such as an agile coach. Choose the indicators in advance and keep the same set for the next rounds, so you can compare.
Explain what it is for
Open by saying the results belong to the team, that they are not a score and that nobody outside will use them to compare teams. Read out both ends of every indicator so everyone starts from the same understanding.
Everyone votes alone
For each indicator, each person picks a color and a trend without discussing first. Voting without seeing other votes keeps the first opinion spoken aloud from pulling the rest.
Reveal the votes together
Show how the votes fell on every indicator at the same time. A split topic, half green and half red, matters as much as an all-red one: it shows that people experience the same topic in different ways.
Talk about red and split topics first
Start with the red topics and the most divided ones. Ask what happened and what made each person choose that color. The conversation is the most valuable part of the health check; do not rush to solutions.
Agree on a color and a trend (optional)
In the original model, the team talks until it reaches consensus: one color and one trend per indicator. In this guide, each person's votes come first. If it helps, after the conversation the team agrees on one color and one trend per indicator for the round's record.
Leave with a few action items
Pick one to three topics to improve and set action items, each with an owner. A few items that move beat a long list nobody comes back to.
Repeat every quarter
The original model suggests starting with one round per quarter: monthly tends to be too often, and twice a year too rare. Start each round with the previous round's action items.
How to read squad health check results
Put the rounds together in a matrix: indicators in rows, rounds in columns, each cell with the color and the trend arrow. The team sees, on one screen, what changed over time.
| Indicator | Q1 | Q2 | Q3 |
|---|---|---|---|
| Easy to release | Red, getting worse | Yellow, improving | Green, improving |
| Tech quality | Yellow, stable | Yellow, getting worse | Red, getting worse |
| Fun | Green, stable | Green, stable | Green, stable |
| Support | Yellow, stable | Red, getting worse | Yellow, improving |
A made-up example of one team over three quarters.
How to read it
- By row: follow one indicator over time. In the example, ease of release improved once the team invested in it, while tech quality got worse two rounds in a row: that is the next topic to discuss.
- By column: see the picture of one round. Many reds at once often point to something bigger, such as a change of priorities or people.
- As a whole: ask whether the team is improving. If the same reds come back every quarter, the action items are not working.
When a company has several teams, the people who lead them can look at results together to find recurring patterns, such as support that every team is missing. The right question is "how can we help?", never "why is this team worse than the others?".
Common squad health check mistakes
- Comparing teams. Every team has its own context, and the model is a self-assessment. Ranking teams makes people hide problems.
- Turning colors into a score. Averages and points erase what matters: how the votes spread and the conversation about it.
- Replacing the conversation with a form. A survey collects colors but takes away the most valuable part: understanding the reason behind each one.
- Pushing toward green. If red is unwelcome, it disappears from the board, not from the team.
- Changing indicators without a note. Adjusting topics is normal, but once an indicator changes, its earlier rounds are no longer comparable. Write down when and why it changed.
- Showing votes in a very small team. With two or three votes, anyone can guess who voted what. In small teams, show the distribution only when there are enough votes.
- Doing nothing with the results. Without action items, and without picking them up next round, the team stops trusting the health check.
What is the difference between a health check and a retrospective?
The two practices complement each other. A retrospective looks at the last sprint and what happened in it; a health check looks at topics that change slowly and shows the trend over quarters.
- Period
- Retrospective: the last sprint or cycle
- Health check: the last few months, compared with the previous round
- How often
- Retrospective: every sprint
- Health check: every quarter, as a starting point
- Question
- Retrospective: what happened and what do we change now?
- Health check: how are we on each topic and where are we heading?
- Format
- Retrospective: cards in columns, votes and discussion
- Health check: one color and one trend per indicator, then discussion
- Output
- Retrospective: action items with an owner
- Health check: the topics that need attention most and a few action items
| Retrospective | Health check | |
|---|---|---|
| Period | the last sprint or cycle | the last few months, compared with the previous round |
| How often | every sprint | every quarter, as a starting point |
| Question | what happened and what do we change now? | how are we on each topic and where are we heading? |
| Format | cards in columns, votes and discussion | one color and one trend per indicator, then discussion |
| Output | action items with an owner | the topics that need attention most and a few action items |
A common way to combine them: the health check points to the red topic, and the next retrospective is dedicated to it. Browse the agile retrospective templates to choose the format for that conversation.
Take your health check results to the next retrospective
Sign in, create your company, invite the team and open a retrospective to discuss the red topics. Leave with action items, each with an owner, and pick them up next round.
Sign in with Google, Slack or a sign-in link sent to your e-mail. No password.
Squad health check FAQ
What is a squad health check?
It is a self-assessment in which a team gives a color (green, yellow or red) and a trend to about ten topics about how it works, then talks about the results to decide what to improve.
Who created the squad health check?
Henrik Kniberg and Kristian Lindwall at Spotify, who published the model in 2014.
How often should we run a health check?
Every quarter is a good starting point. Monthly tends to be too often, and twice a year too rare to see the trend.
How long does a health check take?
One to two hours with the whole team, including the conversation. Voting takes a few minutes; the rest of the time is the part that matters most.
Should the votes be anonymous?
Voting without seeing other votes helps each person give their own opinion. In small teams, show only how the colors are spread, and only when there are enough votes, so nobody can work out who voted what.
Can we change the indicators?
Yes. The original model lets the team change, drop or add topics. Keep the same set between rounds so you can compare, and write down when it changes.
Can we compare health checks across teams?
It is not recommended. A health check is a self-assessment, and every team has its own context. Looking at several teams together is for finding patterns and knowing where to help, not for ranking.
What is the difference between a health check and a retrospective?
A retrospective looks at the last sprint and ends with action items. A health check looks at topics that change slowly, every quarter, and shows the trend of each one. The two complement each other.
Example statements adapted from the Squad Health Check model cards by Henrik Kniberg and Kristian Lindwall (Spotify, 2014), licensed under CC BY-SA. Our adaptation: CC BY-SA 4.0.