Sprint Reporting

🔵 Optional

Use this when: The iteration just ended and you need to communicate what happened — to stakeholders, leadership, or the broader organization.

Quick version: Use the /sprint-report skill in Claude Code for one-command execution.

Why this matters

Sprint reports serve two purposes: accountability (what did we commit to and what did we deliver?) and visibility (what did we learn that changes the plan?).

A good sprint report is concise, honest, and forward-looking. An agent can draft it quickly from your iteration data, freeing you to focus on the narrative and strategic framing.

What to prepare

Before running this workflow, gather:

Iteration plan (what was committed at the start of the week)
Actual outcomes (what was delivered, what carried over, what was dropped)
Demo feedback (reactions from the demo — what landed, what raised questions)
Retrospective highlights (what the team will improve, any process changes)
Metrics (if tracked — velocity, cycle time, test coverage, user metrics)
Any notable learnings (user research findings, technical discoveries, risks surfaced)

The workflow

Step 1: Draft the report

Here's the data from this iteration:

Iteration goal: (what we set out to accomplish)

Committed stories:
(List each story with status: done, carried over, or dropped)

Demo feedback:
(Paste notes from the demo)

Retro highlights:
(Key takeaways from the retrospective)

Metrics:
(Velocity, stories completed, any other data)

Notable learnings:
(Research findings, technical discoveries, risks)

Draft a sprint report with these sections:

1. **Summary** (2-3 sentences: what we accomplished and the key takeaway)
2. **Delivered** (bulleted list of what shipped, described in user-facing terms — not ticket IDs)
3. **Carried over** (what didn't get done and why — be honest)
4. **Key learnings** (what we discovered that affects the plan going forward)
5. **Next iteration preview** (what we're planning to work on next week)
6. **Risks and needs** (anything that could slow us down; anything we need from stakeholders)

Keep it under 1 page. Use plain language — this goes to people who don't read Jira.

Alternative: Pull from GitHub commits

Instead of manually gathering story outcomes, pull sprint data directly from GitHub commits and PRs via the GitHub MCP server. This is more accurate than self-reports and reduces overhead on engineers.

Pull the merged PRs and commits from the last iteration (dates: start to end).

For each PR:
1. Summarize what it delivered in user-facing terms
2. Note the stories or tickets it references

Then draft the "Delivered" and "Carried over" sections of the sprint report
based on what actually merged vs. what was planned.

Caveat: This works best when commit messages and PR descriptions are descriptive. If your team uses terse commit messages, pair this with ticket data from your project management tool for context.

Step 2: Review and refine

Accuracy — Verify every claim. If the agent says something shipped, confirm it's actually deployed.
Honesty — Don't let the agent soften bad news. If two stories carried over because scope was underestimated, say that.
Framing — Adjust the narrative for your audience. Executives want impact and risks. Technical stakeholders want details.
Tone — Rewrite anything that sounds like AI-generated filler. The report should sound like you.

Step 3: Add the strategic layer

The agent handles the data summary well. You add the judgment:

Why carried-over work matters (or doesn't)
How this iteration advances the larger goal
What the team needs from stakeholders (specific asks, not vague requests)

What to review

Check	Why
Delivered items are actually shipped	Don't claim credit for work that's still in staging
Carried-over explanations are honest	"Took longer than expected" is weak; "scope was larger than estimated because of X" is useful
Next iteration preview is realistic	Don't promise what you haven't planned yet
Risks are specific and actionable	"Things might be slow" is useless; "We're blocked on API access from the data team" is actionable

Velocity analysis prompt

If you want a deeper look at trends:

Here's our velocity data for the last (number) iterations:

(Paste: iteration number, stories committed, stories completed, carry-over count)

Analyze the trends:

1. Is velocity stable, improving, or declining?
2. Are we consistently over-committing or under-committing?
3. What's our carry-over rate? Is it improving?
4. Based on the trend, what's a realistic commitment for next iteration?
5. Any patterns worth discussing in the next retrospective?

Common mistakes

Reporting only what shipped — The most valuable sprint reports include what you learned, not just what you built.
Making excuses for carry-over — Be direct about what happened. The team loses trust if you spin every miss.
Skipping the report — Even if nobody asks for it, write it. It forces you to reflect, and it creates a record you'll reference later.
Writing a novel — One page. If stakeholders want more detail, they'll ask. Respect their time.

AI in practice: reporting beyond sprint summaries

This workflow extends to broader operational reporting:

QBR pack automation — Quarterly business review decks assembled automatically: KPIs pulled from data connectors, trend analysis generated, slides formatted. Total prep drops from 3 days to half a day. See Operations & Automation use cases.
Weekly campaign data rollups — Marketing teams automate the pull, analysis, and summary of campaign performance data — ready to share with stakeholders every Monday. See Sales & Marketing use cases.
Compliance reporting — Financial services teams generate regulatory reports in minutes instead of days by pulling from structured data sources. See Financial Services use cases.

Frequency

Once per iteration (weekly). Send it the same day as the demo — ideally Friday afternoon or Monday morning. Consistency builds trust.