Sprint Metrics

Language

Objective

• Consolidate sprint data into concrete numbers
• Feed retro and sprint review with facts, not impressions
• Identify patterns between sprints (improvement or degradation)
• Support capacity and planning decisions

When to use

• At the end of the sprint, before review or retro
• When the team needs data to discuss performance
• To compare sprints and identify trends
• When there is doubt if declared capacity is calibrated

Collected metrics

Delivery

• Total planned stories/items
• Total delivered vs not delivered
• Completion rate (%)
• Items added during the sprint (scope creep)
• Items removed or postponed

Quality

• Bugs found during the sprint
• Bugs found after delivery
• Test coverage (if measurable)
• Lint, typecheck, or test failures at closing

Flow

• Registered blockers (quantity and average duration)
• Average time between story start and completion
• Stories that returned from "done" to "in progress"

Process

• Status checkpoints held vs expected
• Status closure reports generated
• Issues opened vs closed

Process

1. Collect data

• Sprint planning (committed items)
• Issues (opened, closed, blocked)
• Status checkpoints (blockers, progress)
• Status closure reports (executed verifications)
• Commits and PRs (volume of changes)

2. Calculate metrics

3. Analyze trends

• Is the completion rate improving?
• Are blockers decreasing?
• Is scope creep under control?

4. Generate summary

Template

# Sprint Metrics: <Sprint>

## Context
- Project/team:
- Period:
- Declared capacity:

## Delivery
- Planned: X items
- Delivered: Y items (Z%)
- Added during sprint: W items
- Removed/postponed: V items

## Quality
- Bugs during sprint: N
- Bugs post-delivery: N
- Lint/typecheck/tests: passed / failed (detail)

## Flow
- Blockers: N (average duration: X days)
- Average time per story: X days
- Reopenings: N stories

## Process
- Status checkpoints: X of Y expected
- Closure reports: X of Y deliveries
- Issues closed: X of Y

## Trend vs previous sprint
- Completion rate: up/down/stable (X% vs Y%)
- Blockers: more/less/same
- Scope creep: more/less/same

## Highlights for retro
- Positive point:
- Attention point:
- Action suggestion:

Rules

• Metrics are reflection tools, not judgment tools. The goal is to improve the process, not evaluate people.
• Never manipulate numbers to look better. If the sprint was bad, the numbers should reflect that — and the retro should discuss why.
• Compare sprints carefully. Different contexts (vacations, external blockers, team changes) invalidate direct comparisons.
• Metrics without discussion are useless. Always present within a retro or review, never as an autonomous report.

Relationship with the flow

flowchart LR
    A["/agile-sprint"] --> B[execution]
    B --> C["/agile-status"]
    C --> D["/agile-metrics"]
    D --> E["/agile-review"]
    E --> F["/agile-retro"]

/agile-review

/agile-retro

/agile-status