DEV Community: Superevh

Team health check: questions, format and how to act on it

Superevh — Thu, 29 Oct 2026 23:46:48 +0000

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.

How to run a sprint retrospective: a step-by-step facilitator guide

Superevh — Thu, 29 Oct 2026 14:15:54 +0000

Originally published on AIYUN.

To run a sprint retrospective, block 45–90 minutes at the end of the sprint and invite only the team. Open with the reason for the meeting, gather what actually happened, dig into why, agree one to three concrete actions with owners, and close with a quick check on whether the time was well spent. The rest of this guide is the detail: what to prepare, a minute-by-minute agenda, and what to do when the conversation goes wrong.

If you only want new formats to try, see 25 retrospective ideas and formats. This page is about running the meeting itself.

What a sprint retrospective is for

A sprint retrospective is the team's regular meeting to look at how they worked, not what they built, and decide what to change in the next sprint. The 2020 Scrum Guide places it at the end of the sprint and timeboxes it at up to three hours for a one-month sprint, and shorter for shorter sprints. For a two-week sprint, 60 minutes is usually enough.

The output is not a list of complaints. It is a small number of changes the team will actually try.

Before the meeting (15 minutes of preparation)

Check last retro's actions. Did they happen? You will open with this.
Pull a few facts. Sprint goal met or not, what was finished, incidents, unplanned work. Facts keep the discussion away from impressions.
Pick a format that fits this sprint. A hard sprint calls for something different from a quiet one.
Set up the board before anyone joins, with columns, a timer and a place for actions.
Decide who attends. The team, including the Product Owner and Scrum Master. Managers outside the team usually make people more careful about what they say.

A 60-minute sprint retrospective agenda

This agenda follows the five stages from Esther Derby and Diana Larsen's book Agile Retrospectives (2006). Most retro formats only change the middle three stages.

Time	Stage	What happens
0–5 min	Set the stage	Purpose, a one-word check-in, last retro's actions
5–20 min	Gather data	Everyone writes cards silently, then reads them out
20–40 min	Generate insights	Group cards, dot vote, discuss the top two or three
40–55 min	Decide what to do	One to three actions, each with an owner and a date
55–60 min	Close	Quick rating of the retro, thanks

1. Set the stage (5 minutes)

Say why you are here and how long it will take. Many teams read Norm Kerth's Prime Directive: whatever we discover, we believe everyone did the best job they could with what they knew at the time. Then ask each person for one word about the sprint. Everyone speaks once in the first five minutes, which makes them much more likely to speak later.

Finish by reviewing last retro's actions: done, not done, or dropped. Skipping this step is the main reason teams stop believing retros change anything.

2. Gather data (15 minutes)

Give everyone five to seven minutes to write cards silently, one idea per card. Silent writing matters: it stops the first or loudest speaker setting the direction. With prompts like "Went well / Didn't go well / Puzzles us", people then read out their cards briefly, without debate yet.

3. Generate insights (20 minutes)

Group similar cards, give each person three votes, and sort by votes. Discuss the top two or three themes and ask "why" until you reach something the team can influence. Asking "What would have to be true for this not to happen again?" moves a discussion from blame to causes.

4. Decide what to do (15 minutes)

Agree at most three actions. Each one needs an owner, a date and a way to know it worked. "Improve communication" is not an action. "Post blockers in the team channel before 10am stand-up, owner Sam, review next retro" is. If an action needs work, add it to the next sprint backlog so it competes for time like everything else.

5. Close (5 minutes)

Ask everyone to rate the retro from one to five, or say one thing to keep or change about the meeting itself. This takes a minute and tells you when the format has gone stale.

Running a retrospective remotely

Cameras on for the opening if people are comfortable, then whatever works.
Use a shared board that people can join from a link without making an account, so nobody loses the first ten minutes to sign-up.
Hide cards while people write so ideas don't anchor on each other, then reveal them together.
Use a visible timer for each stage; remote meetings drift faster.
Call on people by name, gently, in a fixed order for check-ins, so quieter teammates aren't left out.

RetroLift does all of this in the browser: hidden cards, voting, a timer, action items carried into the next retro, and themed templates when the usual format gets dull. It is free and made by AIYUN, and teammates join from a link or QR code.

Common problems and fixes

Problem	Fix
Same issues every retro	Check whether past actions were done. If they weren't, the real issue is follow-through, so make that the topic.
One person dominates	Silent writing first, round-robin read-outs, and a timer per speaker if needed.
Nobody says anything negative	Make cards anonymous, ask about the process rather than people, and leave the manager out.
Too many actions, none done	Cap at three, give each an owner, and put them on the sprint board.
It feels like a ritual	Change the format, change the facilitator, or try a Lean Coffee retro where the team sets the topics.
Low energy at the start	Open with a short icebreaker, or a quick team health check to give the discussion a focus.

Frequently asked questions

How long should a sprint retrospective be?

The Scrum Guide sets a maximum of three hours for a one-month sprint and less for shorter sprints. In practice, 45 to 60 minutes works for a two-week sprint and 90 minutes for a month. If you regularly run out of time, cut the number of topics you discuss rather than rushing the actions.

Who should facilitate a sprint retrospective?

Often the Scrum Master, but anyone on the team can. Rotating the facilitator every few sprints brings new formats and lets the Scrum Master take part as a team member. The facilitator keeps time and makes sure everyone is heard; they don't decide the actions.

What is the difference between a sprint review and a sprint retrospective?

The sprint review looks at the product: what was built, shown to stakeholders, with feedback on what to do next. The retrospective looks at the team's way of working and is usually just for the team. The review comes first, then the retrospective closes the sprint.

What should come out of a sprint retrospective?

One to three specific improvement actions, each with an owner and a date, that the team will try in the next sprint. A good retro also leaves people feeling heard, but the actions are what make the next sprint different.

Disclosure: I build RetroLift and the other free Lift Apps tools mentioned here.