Run it in five steps
- Say what the check is for and who will see the results, before anyone answers anything.
- Ask everyone the same questions individually, in writing, before any group discussion.
- Look for spread rather than averages. Where answers disagree is where the real issue sits.
- Agree one change, give it an owner and put it in the next Sprint Backlog.
- Ask the same questions next quarter so you can see whether anything moved.
The questions worth asking
Keep the set short. Fifteen specific questions produce more usable material than sixty generic ones, because people answer all fifteen properly.
Sprint Goal and focus
- Can every person state the current Sprint Goal in one sentence without checking the board?
- When something urgent arrives, is there a visible trade-off, or does the work simply get added?
- How often does the team finish a Sprint having delivered what the goal described?
Flow and finishing
- How many items are in progress at once compared with the number of people?
- What is the longest an item has sat waiting on someone outside the team this month?
- Does work carry over most Sprints, and does anyone know why?
Quality and Definition of Done
- Is there a shared Definition of Done, and does the team apply it when a deadline is close?
- How much of the last Sprint went on defects from earlier Sprints?
- Could the team release at the end of the Sprint if it decided to?
Decisions and safety
- Who decides how much work goes into a Sprint in practice, not in theory?
- Has anyone disagreed with a decision in the last month in front of the whole team?
- Do difficult topics come up in the Retrospective, or in private afterwards?
Stakeholders and value
- Does the team hear what happened to what it built?
- Do requests reach the Product Owner, or arrive directly with Developers?
- When was the last time something was removed from the backlog because it stopped mattering?
What usually goes wrong
The most common failure is turning the result into a score that gets compared across teams. The moment that happens, people answer to protect the team rather than to describe it, and the data becomes worthless.
The second is running the check and never closing the loop. If nothing visible changes, the next round gets shorter answers, and the round after that gets no answers at all.
The third is asking only the Scrum Master. One person's view of how a team works is a hypothesis, not a diagnosis. The value comes from comparing what different people say about the same team.
Or let the tool do the collection
How Scrum Is Your Team asks each person what should happen, what would happen and what actually happens, keeps individual answers private, and returns a report with the gaps and concrete actions. Free during the Scrumling pilot.
See how the assessment worksFrequently asked questions
What is a Scrum team health check?
A structured check on how a team actually works, covering focus, flow, quality, decision making and stakeholder relationships. It is not an audit and it is not a performance review. The output should be one or two changes the team agrees to make, not a score.
How often should you run one?
Every quarter is enough for most teams. Running it monthly turns it into a chore and the answers stop changing. Running it once a year means you are diagnosing history rather than the present.
Who should take part?
Everyone in the Scrum Team, including the Product Owner and Scrum Master. Leaving anyone out is exactly how you miss the disagreement that matters. If a manager takes part, be explicit about whether responses are anonymous.
Should answers be anonymous?
Usually yes. The point of the exercise is to surface what people would not say in a meeting. Anonymity only works if the group is large enough that individual answers cannot be identified, so aggregate and report by theme rather than by response.
What do you do with the results?
Pick the largest gap between what people say should happen and what they say actually happens, agree one change with an owner, and put it in the next Sprint Backlog. Then re-check the same question next quarter.
Is a health check the same as a maturity assessment?
No. Maturity models rank teams against a scale. A health check looks at what is getting in the way right now. Teams tend to act on the second and argue about the first.