Automate Sprint Retrospective Reports

The Problem

It's Friday afternoon, sprint retro time. The engineering manager asks "what went well?" and gets silence. Then "what didn't go well?" and gets vague complaints about "too many meetings" and "unclear requirements." The retro devolves into the same 3 people talking about the same 3 problems every 2 weeks. Everyone knows the meeting is supposed to help, but it feels like a ritual — predictable, repetitive, and ultimately toothless.

The real story of the sprint lives in the data: Git commits, PR review times, ticket cycle times, deploy frequency, and incident logs. But nobody has time to compile this before the meeting. Without data, retros become opinion-driven sessions where the loudest voice wins and recency bias dominates. "Reviews take too long" has been on the board for months — but nobody can say whether it's getting better or worse, or quantify the impact. The same issues get raised, the same vague action items get written, and the same problems persist. It hits different when you can show that the average PR sat for 26 hours before first review, and that one person is carrying 26% of the review load.

The Solution

Using the github skill to pull PR and commit activity, data-analysis to identify patterns and bottlenecks, and report-generator to produce a structured retro document, the agent turns raw repository data into a sprint narrative the team can actually discuss — with numbers that prove or disprove what everyone "feels" is happening.

Step-by-Step Walkthrough

Step 1: Gather Sprint Data from GitHub

The agent starts by pulling everything from the repository for the sprint window. No manual spreadsheet assembly, no guessing which PRs landed this sprint versus last:

Pull all activity from our repo for sprint 23 (Feb 3-14). Get PRs merged,
review times, commit patterns, and CI failure rates. Include per-developer
breakdowns for reviews given and received.

The raw numbers for Sprint 23 (Feb 3-14):

The distribution numbers tell a deeper story than the averages. Average first review takes 26.3 hours — but the median is 14 hours, which means a few PRs are sitting for days and skewing the mean. Merge after approval takes 4.1 hours. Average PR is 247 lines. The largest PR clocks in at 1,842 lines — a billing refactor that nobody wanted to review because of its size.

And the review load is wildly uneven: Noa gave 23 reviews, while Wei and Sam gave 2-3 each. That's not a distribution — it's a dependency on one person.

Step 2: Analyze Patterns and Trends

A single sprint's numbers show what happened. But patterns only emerge when you compare across sprints — is review time getting worse, or was this sprint an anomaly? Is the CI pass rate a trend or a blip?

Analyze the sprint data. Compare against the last 3 sprints. Identify trends, bottlenecks, and anomalies.

The trend analysis across four sprints reveals patterns invisible in any single sprint:

Three bottlenecks stand out:

1. Review time up 44% over 4 sprints — Noa handles 26% of all reviews. The team doesn't have a generic "reviews are slow" problem; it has a Noa dependency problem. When Noa is in focused coding mode or on PTO, the entire review pipeline stalls.
2. CI pass rate down 8 points — 11 of the 24 failures trace back to the same flaky test in the payments module (payments/checkout.spec.ts). One test is responsible for nearly half the CI noise, and it's been failing intermittently for 3 sprints without getting fixed.
3. PR sizes creeping up — 4 PRs exceeded 500 lines this sprint. Larger PRs take longer to review (the 1,842-line PR sat for 3 days), which feeds back into the review time problem. It's a compounding cycle.

On the positive side: zero production incidents (first clean sprint in 6 cycles), and Kai, the new hire, shipped 3 PRs in week 2 — the fastest ramp-up the team has seen.

Step 3: Generate the Retrospective Report

The raw analysis is useful for the engineering manager, but the retro meeting needs a document the whole team can discuss — organized around what to celebrate, what to fix, and what to do about it:

Create a sprint retrospective report with sections for what went well,
what needs attention, specific action items, and team shoutouts. Include
the data to back up every claim. No vague observations — every "needs
attention" item should have a number attached.

Sprint 23 Retrospective Report (Feb 3-14)

Dashboard: 31 PRs merged | 187 commits | 7 deploys | 0 incidents | 83% CI pass rate

What Went Well

• Zero production incidents — first clean sprint in 6 cycles
• Kai (new hire) shipped 3 PRs in week 2, fully ramped
• Billing refactor landed (1,842 lines) without breaking anything
• Deploy cadence held steady at 3.5/week despite review delays

What Needs Attention

• Review time up 44% over 4 sprints (now 26h average). Noa handled 26% of all reviews while Wei and Sam averaged 2-3 each. Suggestion: rotate review assignments with a round-robin bot, set an 8-hour SLA for first review.
• CI reliability declining (83% pass rate, was 91% four sprints ago). 11 of 24 failures from the same flaky test in the payments module. Suggestion: fix or quarantine payments/checkout.spec.ts this sprint.
• PR sizes creeping up (247 avg lines, was 189 four sprints ago). 4 PRs exceeded 500 lines this sprint. Suggestion: add a CI warning at 300 lines encouraging developers to split into stacked PRs.

Action Items

1. Fix flaky test: payments/checkout.spec.ts — owner: Sam, by Sprint 24 Wednesday
2. Set up round-robin PR assignment in GitHub — owner: Noa, by Sprint 24 Monday
3. Add PR size warning at 300 lines in CI — owner: Amir, by Sprint 24 Friday

Shoutouts

• Noa: 23 reviews this sprint, keeping the team unblocked (even though the load is unsustainable)
• Kai: fastest ramp-up in team history, 3 quality PRs in first full week
• Team: first zero-incident sprint in 3 months

Step 4: Track Action Item Follow-Through

The retro report is useless if nobody follows up. The biggest failure mode of retrospectives isn't generating the wrong insights — it's writing action items that never get done. Checking the historical record:

Check which action items from the last 3 retros were actually completed. Show the follow-through rate.

Overall follow-through: 58%. Nearly half the action items from retros never get completed. The team is generating insights faster than it's acting on them.

Worse: two items keep recurring without resolution. "Reduce flaky tests" appeared in S20, S21, and S23 — three retros, same problem, never fixed. "Distribute review load" appeared in S21 and S23. The same problems keep surfacing because the action items are too vague ("reduce flaky tests") instead of specific ("fix payments/checkout.spec.ts, owner: Sam, by Wednesday").

Recommendation: limit action items to 3 per sprint (not 4-5), assign explicit owners, and set concrete deadlines. Fewer commitments, more completions. Track follow-through in every retro report so the team can see whether things are actually changing.

Real-World Example

Jess, engineering manager at a 12-person product team, ran the same retro format for 8 months. The team always said reviews were slow and tests were flaky, but nothing changed. Without data, she couldn't prioritize which problem mattered more, prove it was getting worse, or assign meaningful ownership.

She ran the analysis workflow before the next retro. The data showed review time had increased 44% over 4 sprints — a trend completely invisible in weekly experience but obvious in the numbers. More striking: one engineer was doing 26% of all reviews while two others averaged 2-3 per sprint. The problem wasn't "reviews are slow" — it was "we're dependent on one person for a quarter of our review capacity, and that person is burning out."

She projected the report in the retro meeting. For the first time, the discussion was specific: not "reviews are slow" but "reviews average 26 hours and Noa is carrying 26% of the load." The team agreed on 3 targeted actions with owners and deadlines. She tracked follow-through in the next sprint's report — 2 of 3 completed, and review time dropped to 18 hours. The retro went from a ritual everyone endured to a tool that actually changed how the team worked.