PR Review Bottleneck: Make Approval-Pending Work Visible

PR Review Bottleneck: Make Approval-Pending Work Visible

The developer finished the task and opened a PR. Now they're waiting. One day passed, two days passed. No review came. The developer moved on to another task. The review finally arrives — but the developer is no longer in that context. Switching back requires a context switch, and time gets lost.

The PR review bottleneck is the most common but least visible source of delay in startups. Nobody is intentionally delaying reviews. But when everyone is focused on their own work, PRs waiting for review quietly disappear from the list.

Why PR Waiting Is Invisible

There are three reasons why a PR waiting for review doesn't surface in the system.

The task gets counted as "done." The developer opened the PR and marked the task as complete in their list. But the work isn't actually done — it's waiting for review and merge. This in-between state is visible nowhere.

Review ownership is unclear. "The team will review it" gets said, but everyone on the team is busy with their own work. Who will take the review isn't written down. Everyone assumes someone else is looking.

Wait time isn't measured. How many days has the PR been waiting? That information exists in GitHub, but it's not visible in the team's working system. A PR that's been waiting a week and a PR that was opened yesterday sit in the same list.

WAITING and REVIEW Statuses in Alios

To make the PR review bottleneck visible in Alios, two statuses get added to the standard status flow: WAITING and REVIEW.

🔄 In Progress → developer actively working
⏳ Waiting → PR opened, reviewer assigned, waiting
👀 In Review → reviewer actively inspecting
🔵 Fix Requested → changes requested, developer revising
✅ Done → merged, task complete

When a PR is opened, the task node automatically moves to "Waiting" status and a reviewer gets assigned. These two steps are what bring the PR into the system.

What Gets Added When Moving to WAITING

⏳ PR OPENED — [Date / Time]

PR link: [GitHub / GitLab URL]
Branch: [Branch name]
Reviewer: [Assigned person]
Review deadline: [Expected date — per SLA]

Summary of changes:
[What changed, why — 2-3 sentences]
[Scenarios that need to be tested]

Needs special attention:
[Any risk, dependency, or context the
reviewer should know about]

What Gets Added When Moving to IN REVIEW

👀 REVIEW STARTED — [Date / Time]
Reviewer: [Name]
Estimated completion: [Time or date]

This transition signals that the reviewer has seen the PR and is actively looking at it. The question "has anyone looked at this?" disappears.

Team Review SLA

SLA (Service Level Agreement) sounds like an enterprise concept, but it's valuable for small teams too. When the answer to "how quickly should PRs be reviewed?" is written down, expectation management becomes possible.

Example SLA for a small technical team:

📋 PR REVIEW SLA — [Team Name]

Critical (hotfix, production bug):
→ Review start: within 2 hours
→ Review complete: same day

High priority (active sprint task):
→ Review start: within the business day
→ Review complete: 24 hours

Normal (feature, improvement):
→ Review start: within 24 hours
→ Review complete: 48 hours

Small (documentation, minor fix):
→ Review start: within 48 hours
→ Review complete: 72 hours

This SLA gets recorded in Alios as a "Review SLA" node. Each time a PR is opened, the review deadline gets calculated based on the priority level and written into the node.

What happens when SLA is exceeded? The deadline in the Waiting node has passed but it's still open — this signal becomes automatically visible. On Monday morning, a "PRs with exceeded SLA" filter gets run.

Monday Morning PR Review Scan

⏱️ 10 MINUTES

[ ] Nodes in "Waiting" status listed
    How many days waiting?
    SLA exceeded?

[ ] Nodes in "In Review" for more than 24 hours
    Is the reviewer blocked, do they need help?

[ ] Nodes in "Fix Requested" for more than 48 hours
    Has the developer not made the fixes? Why?

[ ] PRs that need to be merged this week identified

Node Description for Review Quality

A review isn't just "approved / changes requested." When what was learned during the review gets written into the node description, team memory builds up.

👀 REVIEW NOTE — [Date]
Reviewer: [Name]
Result: [ ] Approved  [ ] Changes requested

Positives:
[What was written well — 1-2 items]

To improve:
[What was asked to change — specific]

Learning note:
[Is there something the team can learn from
this PR?]

This note can be referenced the next time a similar task comes up. The same feedback doesn't need to be given repeatedly.

Final Thought

The PR review bottleneck isn't unavoidable. But without making it visible, it can't be managed.

In Alios, WAITING and REVIEW statuses, reviewer assignment, and SLA tracking build this visibility. The question "when will this PR get merged?" gets answered by looking at the node. Review delays get caught in the weekly scan.

The developer doesn't open a PR and disappear into the wait — the PR is visible and being tracked.