Sprint Velocity AnalysisCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: sprint-velocity-analysis
description: "Analyze sprint velocity data and produce an engineering team health report covering delivery trends, capacity utilization, and improvement recommendations. Use when asked to analyze sprint velocity, review team delivery health, identify delivery risks, or produce a retrospective data analysis. Produces a velocity trend analysis, health diagnosis table, top improvement recommendations with implementation steps, and a next-sprint capacity forecast."
---

# 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

| Sprint | Committed | Completed | Completion Rate | Carried Over | Notes |
|--------|-----------|-----------|----------------|--------------|-------|
| [Sprint N] | [X pts] | [X pts] | [X%] | [X pts / X items] | [disruption or context] |
| [Sprint N+1] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+2] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+3] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+4] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+5] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+6] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| [Sprint N+7] | [X pts] | [X pts] | [X%] | [X pts / X items] | |
| **Average** | **[X pts]** | **[X pts]** | **[X%]** | **[X pts]** | |

### 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

| Metric | Value | Interpretation |
|--------|-------|----------------|
| Average velocity | [X pts/sprint] | [Baseline for planning] |
| Velocity std deviation | [±X pts] | [Low < 15% of avg = stable; High > 25% = erratic] |
| Trend direction | [Improving / Flat / Declining / Erratic] | [3-sprint trailing average vs. 3-sprint leading average] |
| Average completion rate | [X%] | [Healthy: 80–95%; < 75% = chronic over-commitment] |
| Carry-over rate | [X% of committed points carried over per sprint] | [Healthy: < 15%; > 25% = systemic issue] |
| Sprints with completion rate < 75% | [X of 8 sprints] | [> 3 of 8 = structural problem, not noise] |

---

## Story Point Calibration

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

| Signal | Observed | Interpretation |
|--------|----------|----------------|
| High variance in velocity despite stable team size | [Yes / No] | Suggests inconsistent estimation — same effort scored differently week to week |
| Consistent over-commitment (committed >> completed) | [Yes / No — by avg X pts per sprint] | Team is sandbagging estimates or ignoring historical capacity |
| Consistent under-commitment (completed >> committed by > 20%) | [Yes / No] | Team is over-padding estimates or pulling in unplanned work frequently |
| Frequent large items (> 13 pts) in carry-over | [Yes / No] | Items are too large to estimate reliably — need better decomposition |
| Velocity cliff after team change | [Yes / No — Sprint N+X] | Team did not re-baseline capacity after composition changed |

**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.

| Sprint | Carried-Over Items | Common Themes in Carry-Over |
|--------|-------------------|----------------------------|
| [Sprint N] | [X items / X pts] | [Technical debt, dependency blocked, scoped wrong, etc.] |
| [Sprint N+1] | [X items / X pts] | [Theme] |
| [Sprint N+2] | [X items / X pts] | [Theme] |

**Carry-over root causes identified:**
- [Ro

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.