Sprint retro with evidence

I'm facilitating my squad's retrospective and I want the conversation to start from what actually happened, not from whoever speaks first. ## Context - Squad: [squad] - Sprint that just ended: [start date] to [end date], compared with the sprint before it (same length). DevStats returns sprint names and totals, not dates, so they have to come from me. - Unit: [issues | story points] - The data opens the conversation. It does not close it. The team decides what it means. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats (both sprints, same filters) 1. Sprints and Planning Accuracy — committed vs completed 2. Throughput — PRs opened and merged 3. PR Cycle Time with the coding / pickup / review / deploy breakdown 4. Issue Cycle Time 5. Code Review — PR size, comments per review, PRs merged without review 6. Work Breakdown — new code vs refactor vs rework 7. Issue List resolved in the sprint, sorted by cycle time descending, limit 20, fields key, summary, issue_type, project, story_points, cycle_time_formatted, history ## How to analyze - Start with plan vs outcome. Completed well below committed is not a delivery problem until you know how much work entered mid-sprint. Bugs and hotfixes resolved in the sprint are the usual source of unplanned load. - Read the status history of the slowest issues. An issue that went back from review or QA to in progress is rework. Several of them is a pattern: unclear acceptance criteria, late feedback, or PRs too large to review well. - Rework share up in Work Breakdown plus more review comments points to requirements or design clarity, not to coding skill. - Look at what the five slowest issues have in common: same project, same type, same dependency. A shared trait is a theme. Five unrelated stories are just five stories. - Find one thing that went well and is visible in the data. A retro that only shows problems makes the team defensive. - Three themes at most. A retro that tries to fix seven things fixes none. - Talk about the system, never about individuals. No names anywhere in the output. ## Deliver A facilitation guide I can run the meeting from: 1. **The sprint in five numbers** — committed, completed, PR cycle time, issue cycle time, rework share, each with the previous sprint next to it. 2. **What went well** — one or two points, with the evidence. 3. **Three themes** — for each one: what the data shows, a neutral opening question for the team, and what the data cannot explain. 4. **Experiments** — one candidate per theme, small enough to run in a single sprint, with the metric that will tell us whether it worked. 5. **Check next retro** — the numbers to look at first in two weeks.