# Where the App squad's PR flow loses time

Last 30 days, compared with the 30 days before. Source: DevStats MCP.

**Short version:** the flow is healthy and it absorbed 40% more PRs without slowing down. The time that is lost is lost *after* merge, waiting for a release, and most of the excess comes from one project that shipped as a batch. Fix how stacks ship before touching review.

## 1. Where the time goes

| Stage | This period | Previous | Share of stage time (now / before) |
|---|---|---|---|
| Coding | 3h 32m | 3h 14m | 7% / 6% |
| Pickup | 15h 19m | 15h 48m | 32% / 31% |
| Review | 4h 44m | 2h 37m | 10% / 5% |
| **Deploy** | **1d 1h** | **1d 5h** | **51% / 57%** |
| Total cycle time | 2d 9h | 2d 3h | |

Deploy owns half of the time and pickup owns a third. Together they are 83% of the stage time, and neither is about how long it takes to write or review code. Coding plus review, the part where people are actually working on the PR, is 8h 16m.

Volume went up a lot: 324 PRs merged against 232 (up 40%), 472 reviews completed against 276 (up 71%). Cycle time moved from 2d 3h to 2d 9h. The system took the extra load without breaking.

## 2. Why, most likely

**Merged work waits for a release.** A PR spends 1d 1h between merge and production, five times longer than it spends in review. That is the release process, not the PR and not the reviewers. The outliers below show the mechanism: PRs from the same project have deploy waits within seconds of each other, which means they went out together in one release.

**Pickup is a standing queue, not a spike.** 15h 19m now, 15h 48m before. It did not react to 40% more PRs or to 71% more reviews. A number that flat is a habit: PRs wait roughly one working day for someone to start, whatever the load.

**What the evidence rules out: slow or skipped review.** Review time did grow (2h 37m to 4h 44m), but comments per review also grew (0.12 to 0.29), so reviewers are engaging more, not parking PRs. PRs merged without review: 0 in both periods. Average PR size is 293 lines (276 before), under the ~400-line mark where review time starts to blow up. Review is 10% of the time. Do not start there.

## 3. The outliers

The 15 slowest PRs of the period (out of 324) are two stories, not fifteen.

**One project, 14 PRs: the Devin AI Activities report** (#7406, #7407, #7409, #7410, #7411, #7412, #7421, #7423, #7424, #7426, #7428, #7429, #7431, and the close-out #7501).

- Coding time is 0 on twelve of them: they were opened as a stack, already written.
- They waited in pickup in two groups: #7406–#7411 for 16h 46m to 20h 32m, then #7421–#7431 for 3d 17h to 3d 19h. #7412 waited 4d 14h.
- After merge they waited for release in three batches: 10d 2h–10d 4h (#7406, #7407, #7409), 6d 2h (#7410, #7411, #7412), and 5d 19h (#7421–#7431).
- Review itself was short: between 0 and 8h 7m.
- The close-out PR #7501 is 10,692 lines with one review and 0 review time.

Every one of these PRs took 9d 21h to 10d 22h end to end, and almost none of it was work. One of them, #7424, is the feature flag that gates the report. The flag existed, and the stack still waited for a single launch.

**One long-lived branch: #7192 (SUP2-849, Azure Boards task not found).** 21d 20h total, of which 21d 15h is coding time. Once the PR was opened it was picked up in 2h 38m and reviewed in 2h 31m. The PR was never slow. The branch was.

This is an outlier problem, not a system problem. But the outliers point at the same two stages the averages do: deploy and pickup.

## 4. First move

**1. Ship stacked PRs behind the flag as they merge.** The Devin stack already had a feature flag (#7424) and still waited 5d 19h to 10d 4h for release. For the next project stack, merge the flag first and release each PR as it merges. Number that should move: deploy time, from 1d 1h to below pickup time (15h 19m). We should see it in the next 30-day window, as soon as one stack ships this way.

**2. Make first review a same-day habit.** Pickup has been 15h for two periods running regardless of load. Agree on who picks up by default (a rotation, or the author names a reviewer when opening) and look at pickup again in two weeks. For stacks, review the whole stack in one sitting: the second Devin group sat 3d 17h in pickup while the first group was picked up in under a day.

**3. Open a draft PR for every branch older than a few days.** Aging Branches shows 20 open branches, 16 of them in Coding and 13 of those red (9+ days). Only 1 is waiting for pickup, 2 are in review, 1 is waiting for merge, and the open PR queue is 3 PRs with the oldest at 1d 19h. So today's pile is not where the historical time went. It is invisible work with no PR, and #7192 is what those 13 branches turn into: 21 days of coding nobody could see, then a fast review. Go through the 13: draft PR, or delete.

## 5. What the data cannot tell me

- Was the Devin stack held for a launch date on purpose, or did it wait because nobody owned the release? If it was a deliberate launch, the deploy number is a choice, not a problem, and move 1 is about making that choice explicit next time.
- Are the 13 red branches real work in progress or abandoned experiments? The tool counts them the same way.

---

*Stage shares are each stage's time divided by the sum of the four stages (the stages do not add up to total cycle time because they are averaged separately). Per-PR durations are converted from the seconds returned by PR List.*