Originally published on AIYUN.
A team health check is a short, regular conversation about how the team is doing: not the work itself, but the conditions around it. Is it easy to release? Do people know why the work matters? Are they learning, or just grinding? Teams rarely say they are struggling until it shows up as missed deadlines or people leaving. A health check gives them a safe, routine way to say it earlier.
This guide gives you a ready-to-use set of questions, a format that works in 45 minutes, and, most importantly, what to do with the results.
Where the squad health check comes from
The best-known version is the squad health check model that Henrik Kniberg and colleagues published on the Spotify Labs blog in 2014. Teams rated themselves on around ten areas using a traffic light (green, yellow, red) and showed whether each area was getting better or worse. Each area had a short description of what "awesome" and "crappy" looked like, which made the conversation concrete.
Two ideas from that model are worth keeping. First, the check is for the team, to help them improve; it is not a report card for management. Second, the trend matters more than any single score.
A squad health check template
Here is a set of ten areas, each with a statement for "healthy" and "unhealthy". Read both aloud, then everyone votes.
| Area | Healthy looks like | Unhealthy looks like |
|---|---|---|
| Delivering value | We ship things that matter to customers and we can see the impact. | We ship a lot, but we are not sure anyone uses it. |
| Easy to release | Releasing is simple, safe and mostly automated. | Releasing is painful, risky and takes days. |
| Code and tech health | We are proud of our code; changes are easy to make. | The code is fragile; every change breaks something. |
| Speed | We get things done quickly, with few waits or blockers. | We are always stuck waiting on something or someone. |
| Mission | We know why we are here and we are excited about it. | We have no idea why we are doing this work. |
| Suitable process | Our way of working fits us, and we can change it. | Our process is imposed on us and gets in the way. |
| Fun | We enjoy working together and have a laugh. | It is a grind and nobody enjoys it. |
| Learning | We are learning interesting things all the time. | We never have time to learn anything. |
| Support | We get help and support when we ask for it. | We keep getting stuck because nobody will help. |
| Players, not pawns | We decide what to build and how to build it. | We are just pawns; decisions are made for us. |
You can add one or two areas that matter to your context, such as Teamwork, Workload ("our pace is sustainable") or Stakeholder relationships. Resist adding many more. Ten is already plenty for one session.
How people vote
Keep the scale simple. Either:
- Traffic light: green (healthy), yellow (some problems), red (needs attention), or
- 1 to 5, if you want a number you can chart over time.
Add an optional trend for each area: better, same or worse than last time.
How to run a team health check in 45 minutes
To run a team health check in 45 minutes, explain the purpose (5 minutes), have everyone vote anonymously on each area (10), reveal the spread together (5), discuss the one or two weakest or most divided areas (20), and agree one or two actions with an owner (5).
- Set it up (5 min). Explain the purpose: this is for us, the results stay with the team, and there are no wrong answers. Say who will see what.
- Vote privately (10 min). Everyone votes on every area, anonymously. Reading a card aloud and having people hold up coloured cards works in a room, but anonymous voting gets more honest answers, especially for areas like Support or Players.
- Reveal together (5 min). Show the spread for each area, not just the average. Five greens and one red tells a different story from six yellows.
- Pick one or two areas (20 min). Talk about the weakest areas, or the ones with the widest spread. Do not try to discuss all ten.
- Agree an action (5 min). One or two concrete actions with an owner, just like a retro.
PulseLift runs this flow for you: share a link, everyone votes anonymously from a laptop or phone, you reveal together, and when you repeat it each sprint or quarter you can see the trend. It is free, made by AIYUN, and nobody needs to sign up.
How often to run it
Most teams run a full health check every quarter: often enough to spot trends, rare enough not to feel like a chore. Run it monthly or every second sprint during big changes, such as a reorg, and keep the same areas and scale each time so the trend means something.
- Every quarter suits most teams. It is often enough to spot trends, rare enough not to feel like a chore.
- Every month or every second sprint works if the team is going through change: a new product, a reorg, a big hiring push.
- Every sprint is usually too often for the full check. If you want something that frequent, use three or four areas only.
Whatever you choose, keep the same areas and the same scale, so the trend means something.
How to read the results
Look at the spread, not just the average
A wide spread is a conversation starter. If half the team says Easy to release is green and the other half says red, the front-end and back-end people may be having very different experiences.
Look at the trend
A yellow that was red last quarter is good news. A green that is sliding toward yellow is an early warning. This is why repeating the check matters more than any single result.
Separate what the team can fix from what it cannot
Some areas, like Fun or Suitable process, are mostly in the team's hands. Others, like Easy to release or Mission, often depend on platform teams, leadership or other parts of the organisation. Be honest about which is which.
How to act on it
A health check without follow-up teaches people that their answers do not matter. Next time, they will just vote green to save time. To avoid that:
- Pick one or two areas, not all of them. Improving one area a quarter is real progress.
- Make actions specific. "Improve release" is a wish. "Automate the staging deploy by the end of next sprint, owner: Priya" is an action.
- Escalate what the team cannot fix. If Mission is red because nobody has explained the strategy, the action is to ask leadership for a session, with a date.
- Put actions on the team board. Treat them like other work so they get time.
- Start the next check by reviewing last time's actions. Did they happen? Did they help?
Sharing results outside the team
This is where health checks often go wrong. If results get compared across teams, or used in performance conversations, people stop being honest and the data becomes useless.
A safer approach:
- The team owns its results and decides what to share.
- When sharing with leaders, share themes and asks ("we need help with release automation"), not raw scores.
- Never rank teams by their health check scores. A team that reports red honestly is more useful than one that reports green because it feels watched.
If leaders want to understand health across many teams, look for patterns: "four of six teams say releasing is hard" is a useful signal about the platform, not about the teams.
Common mistakes
- Too many questions. Twenty areas means shallow votes and no time to talk.
- Changing the questions every time. You lose the trend.
- Skipping anonymity. Especially in teams with a strong hierarchy, or where the manager is in the room.
- Turning it into a survey. The conversation is the point. A form emailed out with no discussion misses most of the value.
- No follow-up. The fastest way to make the next check meaningless.
Frequently asked questions
How often should you run a team health check?
Every quarter suits most teams, and every month or second sprint works during big changes. Running the full check every sprint is usually too often; if you want that frequency, use only three or four areas. PulseLift, a free tool by AIYUN, keeps each round so you can see the trend over time.
Should the manager or Scrum Master vote in a team health check?
Usually the people doing the work vote, and the facilitator does not. If a manager is part of the day-to-day team, they can vote, but anonymity becomes even more important.
Is a team health check the same as a retrospective?
No. A retro looks at the last sprint, while a health check looks at longer-running conditions. Many teams run a health check every few months in place of a regular retro.
What if everything is green in a team health check?
Celebrate, then ask whether people felt safe being honest. If they did, pick the area with the most room to grow and keep improving.
Disclosure: I build PulseLift and the other free Lift Apps tools mentioned here.
Top comments (0)