Use this when the iteration just ended and you need to communicate what happened — what shipped, what carried over, what you learned, and what's next. Produces a concise, one-page report for stakeholders, leadership, or the broader team.

Process

Step 1: Gather iteration data

Ask the user to provide:

Iteration goal — what you set out to accomplish this week
Committed stories and outcomes — list each story with status: done, carried over, or dropped
Demo feedback — reactions from the demo (what landed, what raised questions)
Retro highlights — key takeaways from the retrospective (optional if retro hasn't happened yet)
Metrics — velocity, stories completed, cycle time, or any other tracked data (optional)
Notable learnings — research findings, technical discoveries, risks surfaced

The user can paste raw data in any format — tracker exports, notes, bullet points.

Step 2: Generate the report

# Iteration Report — (Date range)

## Summary
(2-3 sentences: what we accomplished and the key takeaway for this iteration.)

## Delivered
- (Item 1 — described in user-facing terms, not ticket IDs)
- (Item 2)
- (Item 3)

## Carried Over
- (Item 1 — what it is and why it carried over. Be specific: "scope was larger than estimated because of X" not "took longer than expected")
- (None — if everything shipped)

## Key Learnings
- (What we discovered that affects the plan going forward)
- (Research findings, technical discoveries, or process insights)

## Next Iteration Preview
- (What we plan to work on next — current plan, not a commitment)
- (Any new work entering the backlog)

## Risks & Needs
- (Risk 1 — specific and actionable, with what we need from stakeholders)
- (None identified — if no current risks)

Step 3: Review and refine

Ask the user:

Are the delivered items accurate? (Is everything listed actually shipped, not still in staging?)
Are the carry-over explanations honest? (Don't soften bad news.)
Is the next iteration preview realistic? (Don't promise what you haven't planned.)
Does the tone match your audience? (Executives want impact and risks. Technical stakeholders want details.)
Anything to add, remove, or reframe?

Adjust as needed.

Output location

Present the report as formatted text in the conversation for the user to share via email, Slack, or their preferred channel.

Input

Iteration goal: Complete the self-serve cancellation flow so customers can cancel without contacting support, and finish the Stripe webhook reliability fixes
Committed stories and outcomes:
- Self-serve cancellation UI — Done
- Cancellation reason survey (post-cancel modal) — Done
- Stripe webhook retry logic — Carried over (discovered we needed to add idempotency keys throughout, not just on the retry handler; scope was 2x what we estimated)
- Dunning email copy updates — Dropped (deprioritized when webhook work expanded)
Demo feedback: Cancellation flow got positive reactions — "finally, this is clean." One stakeholder asked whether we're logging cancellation reasons to the data warehouse yet (we're not). Finance flagged that they still need the dunning emails before end of quarter.
Retro highlights: Team felt good about shipping the cancellation work cleanly. Frustration that the webhook story wasn't scoped with the payments engineer involved earlier — she caught the idempotency issue in review that should have surfaced in planning.
Metrics: Velocity: 18 points completed / 26 committed. 4 of 5 stories touched, 2 shipped, 1 carried, 1 dropped. Avg cycle time 3.1 days.
Notable learnings: Stripe's webhook docs understate the idempotency requirements for retry scenarios. Any future payments work needs payments engineer in scoping, not just review.

Output

Iteration Report — June 9–20, 2025

Summary

We shipped the self-serve cancellation flow end-to-end, giving customers a clean exit path without involving support. The Stripe webhook reliability work carried over after scoping revealed the fix required idempotency handling throughout the payments pipeline — not just at the retry layer. Velocity came in at 18 of 26 committed points, with one story dropped to protect the webhook work.

Delivered

Self-serve cancellation — Customers can now cancel their subscription directly from account settings without contacting support
Cancellation reason survey — Post-cancel modal collects structured exit reasons; data is visible in the admin dashboard

Carried Over

Stripe webhook retry logic — Carried over because the fix required adding idempotency keys throughout the payments pipeline, not just on the retry handler as originally scoped. Scope was approximately 2x the estimate. On track to complete in the next iteration.

Key Learnings

Stripe's documentation understates idempotency requirements for retry scenarios — this was not obvious until implementation was underway
Payments engineer needs to be in scoping conversations, not just code review; her input in planning would have surfaced the idempotency issue before the story was committed
Cancellation reason data is not currently flowing to the data warehouse — this surfaced as a stakeholder expectation gap during demo and needs to be backlogged

Next Iteration Preview

Complete Stripe webhook retry logic with full idempotency handling (carried over)
Dunning email copy updates (dropped this iteration; Finance has an end-of-quarter dependency)
Begin scoping: routing cancellation reason data to the data warehouse

Risks & Needs

Finance end-of-quarter deadline on dunning emails — This was dropped when webhook scope expanded. Finance flagged urgency; needs a timeline commitment or an explicit conversation about what moves to accommodate it
Payments engineer capacity — She's the only person who can safely own Stripe work. If she picks up other commitments next iteration, webhook completion is at risk. We need visibility into her availability before planning.

Sprint Report