Generating Sprint Metrics Insights

Paste the metrics (CSV, table, or JIRA export) plus the period covered. Example input:

PI 2024.3, Team Phoenix
Velocity: 42, 45, 38, 40 (last 4 sprints)
Predictability: 70% (was 85% in PI 2024.2)
Escaped defects: 6 (was 2)
Cycle time: 4.2 days avg (was 3.1 days)

Output: a short narrative + 3-5 retro questions + 1-2 proposed actions, as shown in the Examples section below. Never invent numbers not in the input.

Progress:

• Step 1: Read and confirm the data — units, period, team/PI scope
• Step 2: Compute trends — direction, magnitude, outliers (only from given numbers)
• Step 3: Write plain-language narrative on predictability, quality, flow
• Step 4: Generate 3-5 retro talking points, each tied to a specific metric, framed as questions
• Step 5: Propose 1-2 candidate actions, clearly labeled as discussion proposals
• Step 6: Flag any claim that the data can't support instead of guessing

Step 1 — Confirm inputs Before interpreting anything, verify:

• What each number means (e.g., is predictability story points or count?)
• The time period / PI(s) covered
• What the RTE/audience cares most about (predictability, quality, throughput)

If units or period are ambiguous, state the assumption explicitly rather than pausing the whole task.

Step 2 — Compute trends For each metric provided:

• Direction: improving / declining / flat
• Magnitude: % or absolute change vs. prior period
• Outliers: single sprint spikes/drops worth flagging

Only use numbers given. Do not extrapolate future values or fill gaps.

Step 3 — Narrative 2-4 sentences per theme (predictability, quality, flow), no jargon, written for an executive or project manager audience who won't read raw charts.

Step 4 — Retro talking points Each point:

• Names the specific metric and the change ("Predictability dropped from 85% to 70%")
• Ends in an open question to the team ("What changed this PI?")
• Avoids asserting a root cause

Step 5 — Candidate actions 1-2 suggestions, explicitly labeled "Proposal for team discussion" — never framed as decisions already made.

Step 6 — Guard insufficient data If a metric has only one data point or missing context, say: "Not enough data to assess a trend for X" rather than guessing.

Example 1: Input:

PI 2024.3, Team Phoenix
Velocity: 42, 45, 38, 40 (last 4 sprints)
Predictability: 70% (was 85% in PI 2024.2)
Escaped defects: 6 (was 2)
Cycle time: 4.2 days avg (was 3.1 days)

Output:

EXECUTIVE SUMMARY — Team Phoenix, PI 2024.3

Narrative:
Velocity held roughly steady (38-45 points/sprint) with no clear trend.
Predictability declined notably, from 85% to 70%, meaning the team
delivered less of what it committed to this PI. Quality softened too —
escaped defects rose from 2 to 6 — while average cycle time grew from
3.1 to 4.2 days, suggesting work is moving through the pipeline more
slowly than last PI.

Retro Talking Points:
1. Predictability dropped from 85% to 70% this PI — what changed in
   planning or mid-sprint scope?
2. Escaped defects tripled (2 → 6) — where in our process are these
   slipping through?
3. Cycle time grew by ~35% (3.1 → 4.2 days) — is this due to larger
   stories, blocked work, or review bottlenecks?
4. Velocity was volatile (42, 45, 38, 40) — did capacity or scope
   change sprint to sprint?

Proposed Actions (for team discussion):
- Proposal: Add a mid-sprint scope-change check-in to reduce
  predictability variance.
- Proposal: Review the Definition of Done for test coverage, given
  the rise in escaped defects.

Note: Only 2 PIs of data were provided, so this reflects a single
period-over-period comparison, not a long-term trend.

Example 2: Input: Velocity: 30 (only one sprint of data) Output:

Not enough data to assess a trend for velocity — only one sprint
provided. Recommend tracking for at least 3 sprints before drawing
conclusions.