Ops & Chief of Staff · Build & Package
Sprint retros based on what actually happened, not what people remember
Doe pulls Jira velocity and carry-over data, GitHub PR review turnaround by reviewer, and CI failure rates, then writes the retro to Confluence with multi-sprint trends, bottleneck analysis, and action items with suggested owners.
Works acrossJiraGitHubConfluence
What you get.
Sprint completion data from Jira, PR review metrics from GitHub, and CI pipeline stats analyzed for patterns like review bottlenecks, estimation drift, and flaky tests. The retrospective lands in Confluence with velocity trends, carry-over analysis, and specific action items.
Retros are driven by whoever talks loudest
Retros are driven by whoever talks loudest and whatever happened most recently. Nobody pulls actual velocity data. The same process problems persist quarter after quarter because the retro is based on feelings, not evidence.
Sprint 14 had 8 carry-over tickets. In the retro, the team blamed "scope creep." But the data shows 3 of those tickets were blocked on PR reviews that sat for 4+ days. The other 5 were estimated at 2 points but took 8. The actual problem is review bottlenecks and bad estimation, not scope creep.
What changes.
- 01Retro data sourceBefore · Memory and whoever speaks upWith Doe · Jira velocity, GitHub PR metrics, and CI pipeline data
- 02Pattern identificationBefore · Same vague complaints sprint after sprintWith Doe · Specific bottlenecks identified with numbers and trends
- 03Action item qualityBefore · "Communicate better" and "plan more carefully"With Doe · "Redistribute PR load from Reviewer X" and "Fix flaky checkout test"
- 04Prep timeBefore · 30-60 minutes pulling data manuallyWith Doe · Retro doc ready in Confluence before the meeting starts
How Doe builds the sprint retrospective
- 01Pulls sprint completion, carry-over, and cycle time dataJiraSprint 14 closed with 34 of 42 story points completed (81% velocity). 8 tickets carried over. 3 tickets were in "In Review" for 4+ days. 2 tickets re-opened after QA. Average ticket cycle time: 4.2 days (up from 3.1 last sprint).
- 02Pulls PR review turnaround, reviewer load, and CI statsGitHub47 PRs merged during the sprint. Average review turnaround: 26 hours (up from 18 hours last sprint). 3 PRs waited 4+ days for first review (all assigned to the same reviewer). CI failure rate: 12% (8 of 67 pipeline runs). Most common failure: flaky integration test in checkout module.
- 03Identifies patterns across velocity, reviews, and CI dataDoe3 patterns: review bottleneck on one team member (assigned 14 of 47 PRs), estimation accuracy declining (actual exceeded estimates by 34% vs 12% last sprint), and the flaky checkout test caused 6 CI re-runs costing ~3 hours. Recommended: redistribute PR review load, recalibrate estimation for backend tickets, fix or quarantine the flaky test.
- 04Writes the retrospective to Confluence with trends and action itemsConfluenceSprint 14 retrospective written with velocity trends (3-sprint graph), carry-over analysis, review bottleneck data, and 3 specific action items with suggested owners.
- 05RecurringEnd of each sprint (biweekly)Biweekly, the data-backed retro lands in Confluence before the meeting with multi-sprint trends and action items with suggested owners. Retro doc written to Confluence.
Up and running in under ten minutes.
- 01Connect your toolsOne-click OAuth for each integration. No API keys, no engineering.
- 02Describe what you need“At the end of each sprint, pull completion and carry-over data from Jira, PR review turnaround and CI failure rates from GitHub, and write a retrospective to Confluence with velocity trends, identified patterns, and specific action items with owners.”
- 03It runs on scheduleRuns at the end of each sprint (biweekly). Retro doc appears in Confluence before the meeting.
Before you delegate.
- 01Does it replace the retro meeting?No. It replaces the data-gathering and pattern-finding that usually happens (or doesn't happen) before the meeting. The team still discusses, but they start from evidence instead of memory.
- 02Can it track patterns across multiple sprints?Yes. Doe stores data from each sprint run and surfaces multi-sprint trends. If the same bottleneck appears three sprints in a row, it flags it as a recurring issue.
- 03What if the team uses story points differently than standard?Doe adapts to however your team uses Jira. If you use T-shirt sizes, time estimates, or custom fields, the analysis adjusts accordingly. The patterns it finds are relative to your own baselines.
- 04Does it identify individual performance issues?Doe identifies systemic bottlenecks, not individual blame. If one reviewer is overloaded, it flags the load distribution as a process problem, not a performance problem. The framing is always about the system.
- 05Can it pull data from Linear instead of Jira?Yes. Doe supports Jira, Linear, and Asana for sprint tracking. The analysis adapts to each tool's data model. GitHub and GitLab are both supported for PR and CI data.