# App squad retro: Cycle 53

Facilitation guide. Cycle 53 (16 days) compared with Cycle 51 (22 days). Cycle 52 lasted 2 days, so it is not a fair comparison. Unit: issues. Source: DevStats MCP.

**How to use it:** the data opens each topic, the team decides what it means. The sprints have different lengths, so compare averages and shares, not volumes.

## 1. The sprint in five numbers

| | Cycle 53 | Cycle 51 |
|---|---|---|
| Committed | 163 issues in the sprint | 66 |
| Completed | 99% done, 1% still in progress | 59 (89.4%) |
| PR cycle time, coding + pickup + review | 1d 10h | 17h 14m |
| Issue cycle time | 2d 16h | 1w 5d |
| Rework share of merged code | 25.6% | 17.3% |

Two notes before the meeting. Cycle 53 is still closing, so its row comes from Sprint Progress and not from the closed-sprint report. And PR cycle time leaves deploy out on both sides, because there is no deploy time recorded for Cycle 51. For Cycle 53 deploy was 20h 39m, which takes the full PR cycle time to 3d 50s.

## 2. What went well

**The sprint closed.** 99% of 163 issues done, against 89.4% of 66 in Cycle 51. The squad took on a much larger sprint and finished it.

**Issues moved faster and the pace held.** Issue cycle time went from 1w 5d to 2d 16h. The squad merged 8.7 PRs per day against 7.4, with smaller PRs (204 lines on average, down from 241) and 0 PRs merged without review in both sprints.

**No ping-pong.** None of the 20 slowest issues went back from In Review to In Progress. When work reached review, it did not bounce.

Say these out loud first. The three themes below are about waiting and visibility, not about the quality of anyone's work.

## 3. Three themes

### Theme 1: finished work waits for review, and leaves in batches

What the data shows:

- PR pickup time went from 7h 53s to 1d 1h. Review time went from 4h 59m to 7h 15m. Coding time went the other way, from 5h 15m to 2h 36m.
- 18 of the 20 slowest issues have an In Review stage, and 16 of them spent 4 days or more in it.
- 12 of the 20 belong to one project, the Devin AI Activity report. Each spent between 3m and 2h 16m In Progress, then between 4d 1h and 5d 0h In Review.
- Those 12 left review in three batches of 7, 3 and 2, each batch within the same minute.

Opening question: *"When a PR is ready, what has to happen before someone picks it up? Walk me through the last one you opened."*

What the data cannot explain: whether the Devin stack waited because reviewers were busy, because it was meant to be reviewed as one piece, or because it was waiting for a release decision. The team knows. The data only shows the wait.

### Theme 2: more code was rewritten, and review talked less

What the data shows:

- Rework share went from 17.3% to 25.6% of merged code, up 8.3 points. New code went from 63.2% to 59.3% and refactor from 19.5% to 15.1%.
- Review conversation went down at the same time: 0.44 comments per review against 0.66, review depth 0.74 against 1.4, and 1.7 reviews per merged PR against 2.1.
- So the extra rework is not coming out of review feedback. It is being found somewhere else.
- One trace of where: 3 of the 12 Devin issues have no Todo stage. They were created and started in the same moment, mid-sprint, as follow-ups to work already in review ("chart should swap per selected card", twice, and the feature flag for the rollout).
- It is not bug load. Bugs and hotfixes resolved in the sprint: 0. In Cycle 51: 1 bug, 0 hotfixes.

Opening question: *"Think of something we rewrote this sprint. Where did we find out it had to change: in review, in QA, in a demo, or after it was merged?"*

What the data cannot explain: whether this rework is healthy iteration on a new report or a sign that the first version was started before the behavior was agreed. Work Breakdown measures rewritten lines. It does not know why they were rewritten.

### Theme 3: the board lags behind the work

What the data shows:

- The two slowest issues of the sprint, DEV-4260 (1w 4d) and DEV-4250 (1w 1d), went from Todo straight to Done. They never passed through In Progress, so their "cycle time" is the time they sat in Todo.
- The 12 Devin issues were In Progress for 3m to 2h 16m each. The code was already written when the card moved.
- 5 of the 20 slowest issues have no Todo stage at all: they were created already started, or carried over from before the sprint.

Opening question: *"If I had looked at the board on day 3, would it have told me what each of us was working on?"*

What the data cannot explain: how much of the drop in issue cycle time (1w 5d to 2d 16h) is real speed and how much is cards being moved late. Both are probably true. Only the team can say in what proportion.

## 4. Experiments for Cycle 54

One per theme, each small enough to run in a single sprint.

**1. First review within one working day, stacks included.** Whoever opens a PR names the reviewer. A stack is reviewed in one sitting by one person instead of waiting to leave together. Metric: PR pickup time, back from 1d 1h toward 7h 53s.

**2. Agree the behavior before the first PR, for one project only.** Pick the next report-sized project. Before coding starts, write down the interactions that tend to come back as follow-ups (what each card, filter and chart does when selected). Label any issue created mid-sprint as a follow-up. Metric: rework share, down from 25.6%, and the number of follow-up issues created mid-sprint (3 found in this one).

**3. The card moves when the branch is created.** Turn on the issue tracker's git automation, or make it the rule for one sprint. Metric: among the 20 slowest issues, how many skipped In Progress (2 this sprint) and how many spent less than an hour in it.

## 5. Check next retro

Look at these first, in this order:

1. PR pickup time. 1d 1h now. Did it move toward 7h 53s?
2. Rework share. 25.6% now.
3. Comments per review. 0.44 now. If pickup drops and this drops too, reviews got faster by getting thinner.
4. Issue cycle time. 2d 16h now. If experiment 3 works this number will go **up**, because cards will start moving on time. That is the board becoming honest, not the squad slowing down.
5. Committed against completed for Cycle 54.

---

*Durations per status come from each issue's status history, converted from seconds. PRs per day is PRs merged divided by the length of the sprint in days. Rework, new code and refactor shares are rounded to one decimal.*