Sprint Velocity Analysis

Sprint Velocity Analysis

Analyze sprint velocity data to produce an honest engineering team health report. The goal is not to generate optimistic-looking charts — it is to surface delivery patterns, identify dysfunction early, and give the team and their manager actionable recommendations. Look for: velocity trends (improving, declining, flat, erratic), story point calibration consistency, carry-over patterns that indicate chronic over-commitment, and capacity-related signals. Produce text-based trend visualizations, a health diagnosis, and specific improvement recommendations with measurable targets.

Required Inputs

Ask for these if not already provided:

• Sprint history — for each sprint: sprint name/number, committed story points, completed story points, and number of items carried over to next sprint; ideally 6–8 sprints minimum
• Team size and any changes — current team size and any additions or departures during the data window
• Known disruptions — holidays, company all-hands, on-call incidents, or other events that affected specific sprints
• Cycle time data (optional) — if available, p50 and p90 cycle time per sprint (time from start to done)
• Definition of Done — what "completed" means for this team (merged to main? deployed to prod? accepted by PO?)

If cycle time data is not provided, omit that section and note it as a recommended data source to add.

Output Format

Sprint Velocity Analysis: [Team Name]

Analysis period: Sprint [N] through Sprint [N+7] ([Date range]) Team size: [X engineers] ([note any changes during period]) Report date: [Date] Data source: [Where this data came from — Jira, Linear, spreadsheet, etc.]

Velocity Trend

Raw Data

Velocity Chart (Completed Points per Sprint)

Points
  60 |
  55 |          ●
  50 |    ●           ●
  45 | ●        ●          ●
  40 |               ●          ●
  35 |
  30 |
     +--+--+--+--+--+--+--+--
      N N+1 N+2 N+3 N+4 N+5 N+6 N+7
      Sprint

  ● = Completed points   — = Average ([X pts])

Generate this chart using ASCII characters based on the actual data provided. Scale the Y-axis to the data range. Plot completed (not committed) points. Mark the average as a dashed line.

Trend Diagnosis

Story Point Calibration

Story points are only useful if they are applied consistently. Look for these calibration signals in the data:

Calibration verdict: [Well-calibrated / Needs recalibration / Severely uncalibrated — one sentence explanation tied to the signals above]

If recalibration is needed: [Specific recommendation — e.g., "Run a calibration session using the last 20 completed items, re-score them as a team, and use the resulting relative sizes to anchor future estimates."]

Carry-Over Pattern Analysis

Carry-over is the most reliable leading indicator of commitment reliability problems.

Carry-over root causes identified:

• [Root cause 1: e.g., "5 of 12 carry-overs were blocked on a third-party API integration — external dependency, not estimation failure"]
• [Root cause 2: e.g., "4 of 12 carry-overs were items estimated at 8+ points that were later found to be 2–3x larger than expected"]
• [Root cause 3: e.g., "3 of 12 carry-overs were interruptions from on-call incidents consuming unplanned capacity"]

Capacity Utilization

Capacity calculation used: [X engineers × Y pts/person/sprint = Z pts available. Adjust: if team capacity changed during the window, note which sprints used which team size.]

Average utilization: [X%] Utilization interpretation: [< 70% = team is under-loaded or over-padding | 70–90% = healthy range | > 90% = no slack for unplanned work — fragile]

Health Diagnosis

Scoring guide: Green = operating within healthy range; Yellow = marginal — watch closely or single-sprint anomaly; Red = chronic issue requiring active intervention.

Overall health: [Green / Yellow / Red] — [One sentence summary: "The team delivers consistently at X pts/sprint but chronic over-commitment is eroding morale and creating a misleading picture for stakeholders."]

Blocker Frequency Analysis

If blocker data was provided, complete this section. If not, note it as a recommended tracking addition.

Top blocker to address: [Name the single highest-impact blocker category and what addressing it would mean for velocity.]