Where is our PR flow losing time?

PRs feel slow and I want to know where the time actually goes before I change anything. ## Context - Squad: [squad]. Repository: [all the squad's repositories] - Period: [last 30 days], compared with the 30 days before it - I want a diagnosis with a first move, not a list of metrics. - 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 periods, same filters) 1. PR Cycle Time — total and coding / pickup / review / deploy 2. Code Review — reviews completed, comments per review, PRs merged without review, average PR size 3. Throughput — PRs opened and merged 4. Aging Branches — branches open right now by stage (coding / pickup / review / merge) and age band 5. Open PRs — the oldest open PRs right now 6. PR List for the current period: sort by cycle time descending, limit 15, fields title, repository, size_total, cycle_time_pickup, cycle_time_review, cycle_time_deploy, review_count, was_reviewed. These are the PRs that define the average; the average hides them. ## How to analyze - First find which stage owns the time. Rank coding / pickup / review / deploy by share of total cycle time and by change vs the previous period. Only investigate the top one or two. - Pickup is the queue before anyone looks. Long pickup means reviewer availability, unclear ownership, or PRs opened late in the week. It is not a review quality problem. - Review is time under review. Long review with many comments per review means genuinely contested changes. Long review with few comments means the reviewer parked it. Check PR size: above ~400 lines, review time grows faster than the size. - Deploy is merge to production. Long deploy is the release process, not the PR. Do not blame reviewers for it. - Coding is first commit to PR opened. Long coding plus big PRs means the work is not being sliced. - Look at the slowest 15 PRs. If three or four of them account for most of the excess, this is outliers, not a system problem. Say which ones and why they were slow: size, no reviewer, stuck in deploy. - PRs merged without review skip the queue. If that share went up while review time went down, the "improvement" is skipped review, not faster review. - Aging Branches is what is stuck now; cycle time is what already finished. The stage where branches pile up today usually matches the stage that owns the historical time. Say whether they agree. - A stage that comes back blank in one period (deploy time is the usual one) was not tracked; it did not take zero time. The totals of the two periods are then not comparable: compare the stages both periods have, and say so. ## Deliver A one-page diagnosis: 1. **Where the time goes** — the stage or stages that own the delay, with both periods and share of total. 2. **Why, most likely** — one or two explanations the evidence supports, and one it rules out. 3. **The outliers** — the specific PRs inflating the numbers, if any, and what happened to them. 4. **First move** — the single change to make this week, which number should move, and by when we should see it. Then the second and third moves, in order. 5. **What the data cannot tell me** — one or two questions to ask the team.