A metric is a quantifiable measure used to assess progress, performance, or operational health. Choose measures that fit the team’s responsibilities and help explain its contribution to an overall management report—not numbers collected merely to make graphs. Agree on goals alongside the measures so a team can tell whether it is meeting expectations. section 6.4.2 section 6.4.3
Make each metric useful and sustainable:
- Match it to the work. Possible measures include open and closed tickets, support interactions, release quantity and timing, performance and load, technical debt paydown, and sprint progress. section 6.4.2
- Collect it without creating a separate reporting project. Where practical, draw on a core tool such as JIRA, SonarQube, or Jenkins. section 6.4.2
- Review it weekly or every two weeks when that cadence gives enough visibility to address emerging problems. Compare a team with its own history or projections, not with unlike teams. section 6.4.2
- Allow time to refine the measures. Use the results to discuss improvements or set new benchmarks, while keeping it safe to report bad news. section 6.4.3
A support team’s measures
A team responsible for onboarding issues and data changes might track time to close resolutions and total interactions in a period. These measures sit alongside a clear charter describing what the team does—and what it passes to development. section 6.1.2
Operational metrics answer a different question: is the system behaving normally? Establish typical CPU, memory, and disk usage, then investigate unexplained spikes or drops. Use those observations to consider when services need more capacity or when resources are no longer required; application logs add context when problems cross systems. section 13.3.2
For staffing, create metrics and review them periodically so hiring decisions respond to changing needs rather than impressions alone. Ask: Does each measure support a decision, and can the team collect and discuss it consistently? section 4.6 section 6.4.2
