Measuring Scrum Team Health: Beyond Velocity
Velocity — the number of story points a Scrum team completes per sprint — has become the default metric for measuring team performance in Agile environments. It is also one of the least useful. Velocity is a lagging indicator: it tells you what happened, not why, and it reveals almost nothing about whether the team is sustainable, the product is healthy, or the organisation is getting what it needs.
Worse, velocity is easily gamed. Teams under pressure to increase velocity learn quickly that re-estimating stories upward achieves the same number without improving anything real. Once velocity becomes a performance target, it stops being an honest measurement. Goodhart's Law — "when a measure becomes a target, it ceases to be a good measure" — applies with particular force in Agile contexts.
A comprehensive team health framework looks across four dimensions: product quality, process health, team health, and stakeholder health. Each dimension has observable indicators that provide a richer, more honest picture than velocity alone.
Dimension 1: Product Quality
Product quality indicators measure whether the team is building the right things well:
Defect rate: the number of bugs discovered post-sprint, particularly those found by end users. A rising defect rate is an early signal of technical debt accumulation or quality shortcuts under delivery pressure.
Test coverage: the percentage of code covered by automated tests. Low or declining test coverage correlates strongly with increased defect rates over time.
Technical debt ratio: the proportion of sprint capacity consumed by rework, bug fixes, and refactoring rather than new functionality. A team spending more than 20–25 per cent of capacity on debt servicing is in a difficult position.
Dimension 2: Process Health
Process health indicators measure whether the Scrum framework is functioning as intended:
Sprint Goal achievement rate: the percentage of sprints where the team achieved its stated Sprint Goal. Consistently missing Sprint Goals — not occasionally, but pattern-level — signals planning problems, scope instability, or external interruption.
Spillover rate: the percentage of sprint backlog items that carry over to the next sprint. Chronic spillover indicates poor estimation, scope creep, or interruption patterns.
Retrospective action follow-through: what percentage of retrospective action items are actually completed? A retrospective that produces action items nobody follows up on teaches teams that retrospectives are performative, not functional.
Dimension 3: Team Health
Team health indicators measure the sustainability and cohesion of the team itself:
Psychological safety: can team members raise concerns, share bad news, and disagree respectfully without fear of negative consequences? This is the foundational condition for everything else. The research of Amy Edmondson at Harvard Business School has demonstrated that psychological safety is the single strongest predictor of team performance.
Team satisfaction: a simple periodic pulse survey — "how satisfied are you with how the team is working together?" — provides a longitudinal signal that individual conversations often miss.
Key-person risk: is any critical skill or knowledge concentrated in a single team member? A team that cannot function when one person is on holiday has a fragility problem that velocity will never reveal.
Dimension 4: Stakeholder Health
Stakeholder health indicators measure the quality of the team's relationship with those who depend on its output:
Sprint Review attendance: are the stakeholders who need to give feedback actually attending Sprint Reviews? Low attendance often signals low stakeholder engagement, which leads to expensive late-stage course corrections.
Product Owner availability: is the Product Owner accessible to the team during the sprint to answer questions and make decisions? PO unavailability is one of the most reliable predictors of sprint failure.
Feedback response time: how quickly does the team incorporate stakeholder feedback after Sprint Reviews? Long feedback loops erode trust and reduce the value of iterative development.
How to Run a Team Health Check
A team health check does not need to be an elaborate process. Start with a simple quarterly check-in using the four dimensions above. For each indicator, have the team rate current performance on a three-point scale: healthy (green), needs attention (yellow), at risk (red). Discuss the reds and yellows. Identify one or two concrete actions to improve in the next quarter.
The goal is not a perfect dashboard — it is an honest conversation. Teams that can have honest conversations about their own health are the ones that improve. The specific indicators matter less than the discipline of looking at them regularly.
XNM Consulting helps organisations build high-performing Agile teams and delivery capabilities. Learn more about our .