← Back to blog

Data-Driven Retrospectives: Go Beyond Opinion

retrospective data metrics

“What do you think of the sprint?” — opinions vary depending on mood, personality, and selective memory. Data tells an objective story that complements and challenges perceptions.

Why Data in Retrospectives

  • Selective memory — we remember the most recent bug, not the 90% that went fine
  • Recency bias — what happened yesterday seems more important than what happened 2 weeks ago
  • Personality — extroverts dominate, introverts stay quiet
  • Endless discussions — “I think that” vs “the data show that”

Essential Data for Retrospectives

1. Sprint Deliveries

MetricPrevious SprintCurrent SprintTrend
Planned points2524
Delivered points2224
Carry-over3 points0

2. Quality

MetricPrevious SprintCurrent SprintTrend
Production bugs24
Critical bugs01
PRs without review10

3. Velocity and Flow

  • Velocity of last 5 sprints: 20, 22, 18, 25, 24
  • Trend: stable, slightly upward
  • Average lead time: 4.2 days (previously: 5.1 days)

4. Estimate vs. Actual

ItemEstimatedActualDifference
PIX Checkout813+63%
User profile330%
Advanced search58+60%
Notifications32-33%

5. Team Health

  • Absences in sprint: 2 days
  • Overtime: 0 (ideal)
  • Overall feeling: 3.8/5 (quick survey)

Tools for Collecting Data

  • Jira/Velocity Chart — velocity and burndown
  • GitHub/GitLab — PRs merged, lead time, review time
  • SonarQube — code quality
  • Dev in Poker — estimate history
  • Quick Survey — 3 questions at the end of the sprint
  • Datadog/Sentry — production bugs and incidents

Data-Driven Retrospective Format

  1. Present the data (5 min) — Scrum Master shows the numbers
  2. Reactions (5 min) — “What surprises you about the data?”
  3. Insights (10 min) — what caused each variation?
  4. Actions (5 min) — maximum 2 actions for the next sprint
  5. Check-out (2 min) — how do you feel about the sprint?

Example of a Data-Driven Insight

Without data: “I feel like we’re delivering less.” With data: “We delivered 24 points vs 22 from the previous sprint, but we had 4 production bugs vs 2. Quality dropped even though delivery was stable. Why?”

Action: “Investigate why bugs doubled and create a pre-release QA checklist.”

Retrospective Health Metrics

The retrospective itself can be measured:

  • Implemented actions from the previous sprint (how many out of how many?)
  • Participation — did everyone contribute?
  • Time — did it stay within the timebox?
  • Follow-up — are actions visible and tracked?

Conclusion

Data transforms retrospectives from a “complaint session” into a “fact-driven diagnosis.” Opinions still matter — data provides the context so that those opinions are informed and actionable.