Sprint Operations
Run the measurement and ceremony layer of a delivery team so planning is grounded in history and reporting is derived from the tracker, not typed in. Tracker-agnostic: works with Jira, Linear, GitHub Issues, or your tracker of choice.
When to use
- Setting up the metric set for a new or inherited team
- Planning a sprint and checking it against real capacity
- Running standup, refinement, review, or retro with a consistent template
- Answering "how is the team doing?" with numbers instead of adjectives
- Writing the sprint report or the quarterly rollup
- Deriving a points-to-hours ratio for finance
- Measuring a team where some lanes are AI coding agents
When NOT to use
- Writing the tickets that go into the sprint (use
ticket-authoring)
- Writing the narrative of a retrospective or postmortem (use
after-action-report)
- Setting objectives and key results (use
okr-design)
- Deciding what ships this quarter (use
roadmap-planning)
- Writing the handoff for an agent lane (use
dispatch-authoring)
- Shaping the readout for executives (use
stakeholder-communication)
Required inputs
- Tracker access or an export with created, started, done, reopened, and sprint fields per ticket
- The team roster and planned availability for the sprint
- The last three to six sprints of history, if they exist
- The team's estimation scale (points, t-shirt sizes, or counts)
- Finance requirements for hours, if the team capitalizes development
If there is no history, say so. The first three sprints set the baseline. Do not invent one.
The framework: 4 parts
Part 1: The measurement set
Eight metrics. Each is derived from tracker timestamps and fields. None is typed into a spreadsheet by hand.
| Metric | One-line definition | Computed as |
|---|
| Cycle time | How long work takes once started | done date minus started date, per ticket; report the median and 85th percentile |
| Lead time | How long a request waits plus takes | done date minus created date, per ticket; median and 85th percentile |
| Throughput | How much finishes | count of tickets moved to done in the period |
| WIP | How much is in flight | count of tickets in any started, not-done state, sampled daily |
| Carryover percent | How much of the plan spilled | committed tickets not done at sprint end, divided by committed tickets |
| Planned vs unplanned ratio | How much of the sprint was the plan | done tickets committed at planning, divided by all done tickets |
| Rework rate | How often done was not done | tickets reopened after done, divided by tickets done |
| Estimate accuracy | How well sizing predicts effort | per size bucket, the spread of cycle times; tighter is better |
Formulas and the tracker fields each needs are in references/metrics-reference.md.
Read metrics as trends across sprints, never as a single number. One sprint is noise. Three is a direction.
Part 2: Estimation and capacity
Points are for forecasting. They exist to answer "how much fits" and "when will it land." They are not a productivity score and are never compared across teams.
Hours are logged separately, and only on capitalizable tickets. If finance needs hours for capitalization, log them on the tickets whose stage is capitalizable. Do not ask the whole team to log every hour so you can convert points.
If finance needs a points-to-hours ratio, derive it. Per team, from trailing history: logged hours on capitalizable tickets divided by points completed on those tickets, over the last three to six sprints. Republish it each quarter with the window it was computed from.
The failure mode of a fixed ratio. A fixed company-wide ratio ("1 point equals 6 hours") drifts away from reality the moment a team's scale, makeup, or work mix changes. It also turns points into a time commitment, so estimates inflate to protect against it. Within two quarters the forecasts get worse and the capitalized hours are wrong.
Capacity is available person-days, minus known absences, minus a buffer for unplanned work set from the trailing planned vs unplanned ratio. Plan to trailing throughput adjusted for that capacity. See references/capacity-checklist.md.
Part 3: Ceremonies
Five ceremonies, each with a fixed purpose and a template.
| Ceremony | Purpose | Output |
|---|
| Planning | Commit to a sprint goal and a set of ready tickets that fits capacity | Sprint goal, committed list, capacity math |
| Daily standup | Surface blockers and WIP problems | Blocker list with owners |
| Refinement | Get the next one to two sprints of tickets to ready | Ready backlog, sized, with open questions owned |
| Review | Show what shipped against the goal | Demo notes, accepted and rejected items, feedback captured as tickets |
| Retro | Change one thing about how the team works | One to three owned actions |
The retro template runs the meeting. The write-up of a significant retro uses after-action-report. Do not duplicate that format here.
Part 4: Reporting
Two reports.
- Sprint report. Goal met or not, the eight metrics with a three-sprint trend, carryover with reasons, notable risks, and agent-lane metrics if any. One page.
- Quarterly rollup. The same metrics across the quarter, the points-to-hours ratio if finance uses one, and the two or three changes the team made and whether they worked.
Both are raw material. Shape the readout for the audience with stakeholder-communication.
Workflow
- Pull the data. Export the last three to six sprints with the fields in
references/metrics-reference.md. Confirm the started and done states are mapped correctly.
- Compute the baseline. All eight metrics, per sprint, plus the trailing median.
- Check capacity. Run
references/capacity-checklist.md for the coming sprint.
- Run refinement. Bring the next sprint's candidates to ready with
ticket-authoring.
- Run planning. Set a goal. Commit to ready tickets up to adjusted trailing throughput. Record the capacity math.
- Run the sprint. Standup daily. Watch WIP and blockers, not hours.
- Close the sprint. Run review, then retro. Capture actions as tickets.
- Report. Fill
references/sprint-report-template.md. Roll up quarterly.
Deep dive: measuring agent lanes
When part of the team is AI coding agents (Claude Code, Codex, or your coding agent of choice), treat each agent lane like a team member with its own row in every metric. The eight metrics still apply. Add five.
| Metric | Definition | Computed as |
|---|
| Dispatches issued | Units of work handed to agents | count of dispatches sent in the period |
| Draft-PR cycle time | Time from handoff to reviewable result | PR marked ready (or draft opened with a complete report) minus dispatch sent; median and 85th percentile |
| Review rework rate | How often agent output needs another pass | agent PRs that needed changes after first review, divided by agent PRs reviewed |
| Honest-stop rate | How often the agent stopped and reported a blocker instead of producing a result | dispatches ending in a reported blocker, divided by dispatches issued |
| Cost per merged PR | What a landed change costs | total agent spend in the period divided by agent PRs merged |
Read them together. An honest-stop rate of zero is a warning, not a win: it usually means blockers are being papered over. A rising review rework rate with a falling cycle time means speed is being bought with reviewer time. Human review time is part of the lane's cost even when it is not in the spend number.
Keep agent and human rows separate in reports so neither distorts the other's trend. Write each handoff with dispatch-authoring so dispatches are comparable.
Failure patterns
- Metrics typed into a spreadsheet. They drift from the tracker and nobody can audit them. Derive everything.
- Velocity as a performance score. Teams inflate points and the forecast breaks. Points forecast; they do not rank.
- Comparing points across teams. Scales differ. Compare trends within a team only.
- A fixed points-to-hours ratio. Wrong within a quarter and it inflates estimates. Derive per team from trailing history and republish.
- Logging hours on every ticket to satisfy finance. Log on capitalizable tickets only.
- Planning to a hoped-for number. Plan to trailing throughput, adjusted for capacity.
- Ignoring carryover. Carryover above about 20 percent for three sprints means planning is broken, not the team.
- Standup as status theater. If nobody leaves with a blocker owned, the meeting did nothing.
- Retro with no owned action. Same complaints next sprint.
- Agent lanes blended into team totals. Hides both the gains and the review cost.
Output format
sprint-[number]-report.md from the sprint report template, one per sprintquarterly-rollup-[YYYY-QN].md with the same metric table across the quarter- Ceremony notes in the tracker or a shared doc, one per ceremony, using the templates
If required data is unavailable
This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.
Reference files