GitHub stacked pull requests turn one large change into a chain of smaller, dependent pull requests. Each layer stays focused. Reviewers can inspect it independently. Teams can keep building without waiting for every lower layer to merge.
That solves the size problem. It does not automatically solve the coordination problem.
A stack can still stall because the dependency order is unclear. A review on the bottom layer can block everything above it. CI failures may repeat across several layers. Reviewers may approve a change without understanding how it affects the rest of the stack. Automatic rebases can move the branches while people are still discussing an older diff.
A stacked pull request retrospective helps the team inspect that workflow while the details are fresh. The goal is not to debate whether stacked PRs are good. The goal is to learn where this specific stack lost time, context, or confidence, then improve the next one.
What Is a Stacked Pull Request Retrospective?
A stacked pull request retrospective is a focused engineering retro held after a meaningful PR stack merges, partially merges, or gets abandoned.
GitHub defines a stack as two or more pull requests in one repository. The bottom pull request targets the trunk, usually main. Each higher pull request targets the branch directly below it. That creates an explicit dependency chain.
The retro reviews the chain as a delivery system:
- Was each layer small enough to understand?
- Could reviewers see the dependency order?
- Where did review time accumulate?
- Did CI give useful confidence on every layer?
- Did rebases or retargeting create repeated work?
- Did the team merge in the intended order?
- What should change before the next stack?
This is different from a code review. The retro does not re-litigate implementation details. It examines how the team planned, reviewed, tested, communicated, and merged the work.
When to Run One
Run the retro when the stack creates enough learning to justify 30 to 45 minutes of team time.
Good triggers include:
- The stack contained three or more layers.
- A lower layer blocked several higher layers.
- Reviewers repeatedly asked for missing context.
- The stack needed several cascading rebases.
- CI behaved differently across layers.
- A partial merge left the remaining branches in an unexpected state.
- AI agents produced changes faster than reviewers could absorb them.
- The stack merged successfully and the team wants to repeat what worked.
Do not wait for a failure. A smooth stack can reveal useful habits worth making explicit.
For broader engineering problems that extend beyond pull requests, use the software development team retrospective guide. For changes spanning product and engineering decisions, the product engineering retrospective gives the discussion a wider frame.
Prepare the Evidence Before the Meeting
The facilitator should create a compact stack map before the retro. Keep it factual.
| Layer | Purpose | Base branch | Review started | Checks passed | Merged |
|---|---|---|---|---|---|
| PR 1 | Shared types | main |
Date/time | Date/time | Date/time |
| PR 2 | API changes | PR 1 branch | Date/time | Date/time | Date/time |
| PR 3 | UI changes | PR 2 branch | Date/time | Date/time | Date/time |
Add only evidence the team can verify:
- Pull request links and layer order
- First review request and first substantive response
- Requested changes that affected higher layers
- Failed checks and repeated failures
- Rebase or retarget events
- Merge order
- Time spent blocked, if the timestamps support it
Avoid turning the preparation into a performance report. The table should help people remember the sequence, not score individuals.
Use a Five-Column Retro Board
Create a board with these columns:
- Stack shape
- Review flow
- Checks and rebases
- Merge and release
- Next-stack rules
Stack Shape
Ask whether the boundaries between layers made sense.
Prompts:
- Which pull request was easiest to review, and why?
- Which layer mixed concerns that should have been separated?
- Did a higher layer depend on an unstated assumption below it?
- Could a reviewer understand each layer without reading the entire stack?
- Was any layer too small to justify its own pull request?
The useful outcome is a rule the team can apply. For example: shared contracts belong at the bottom, behavior changes sit above them, and tests travel with the behavior they verify.
Review Flow
Review timing and ownership without blaming reviewers.
Prompts:
- Where did the first meaningful review happen?
- Did reviewers start at the bottom or jump into higher layers?
- Was ownership clear for every layer?
- Which context had to be repeated across pull requests?
- Did feedback on one layer invalidate work above it?
Look for system fixes. A stack map in every PR description may solve missing context. A named primary reviewer per layer may solve ambiguous ownership. A maximum review-start time may expose overload earlier.
Checks and Rebases
GitHub's current stacked PR workflow applies branch protections and required checks throughout the stack. It can also rebase higher layers when lower layers merge. The retro should ask whether those mechanics created confidence or confusion.
Prompts:
- Did checks run where the team expected?
- Which failure appeared in more than one layer?
- Did the team review the correct post-rebase diff?
- Did a cascading rebase require manual repair?
- Were reviewers notified when a material diff changed?
Do not turn every CI failure into an action item. Choose the failure pattern most likely to slow another stack.
Merge and Release
GitHub supports merging a full stack, one pull request, or a portion of the stack. Pull requests still merge from the bottom upward. The team should agree on the intended merge strategy before the next stack reaches its final review.
Prompts:
- Was the merge plan written down?
- Did the team merge the whole stack or only part of it?
- Did any higher layer remain open longer than expected?
- Could the feature be released safely after a partial merge?
- Did the final commit history match the team's expectations?
If a partial merge would create an unsafe production state, the stack needs a clearer release boundary or feature flag before review begins.
Next-Stack Rules
Finish by converting observations into no more than three rules.
Examples:
- Every PR description links the full stack and marks the current layer.
- A layer should represent one reviewable concern, with its tests in the same layer.
- The primary reviewer starts with the bottom layer within one working day.
- Material post-review rebases require a fresh review note.
- The merge plan is written before the top layer leaves draft status.
Three adopted rules beat twelve forgotten suggestions.
A 40-Minute Facilitation Plan
Use this agenda:
| Time | Activity | Outcome |
|---|---|---|
| 0-5 min | Review the stack map | Shared factual timeline |
| 5-12 min | Add cards silently | Independent observations |
| 12-17 min | Group related cards | Visible patterns |
| 17-22 min | Vote | Top two friction points |
| 22-32 min | Discuss causes | System-level explanation |
| 32-38 min | Write actions | Owners and success measures |
| 38-40 min | Confirm follow-up | Review date for next stack |
Silent card writing matters. It prevents the author of the stack or the most senior reviewer from defining the story before everyone else contributes.
Turn Findings Into Measurable Actions
Weak action: "Review stacked PRs faster."
Better action: "For the next stack, assign one primary reviewer per layer before requesting review. Success means every layer receives a substantive first response within one working day."
Weak action: "Improve CI."
Better action: "Move the shared contract test into the bottom layer and verify that it runs for every layer in the next stack. Owner: platform team. Check after the next three-layer stack."
Weak action: "Explain dependencies better."
Better action: "Add a stack map to each PR description showing the layer above and below. Owner: stack author. Verify during the next review."
Every action needs an owner, a deadline or trigger, and a visible success condition.
What Not to Do
Avoid these common traps:
- Do not judge individual productivity from the number of layers.
- Do not treat every rebase as failure. Some are normal consequences of dependency changes.
- Do not use the retro to conduct a second line-by-line code review.
- Do not create actions for problems outside the team's control without naming an escalation path.
- Do not assume smaller always means better. A layer that cannot be understood or tested independently is not reviewable merely because its diff is short.
- Do not delete the practices that worked. Record them as next-stack rules.
Start the Retro While the Stack Is Fresh
The best time to inspect review and merge friction is immediately after the stack resolves. The branch order, CI failures, and review handoffs are still visible. The team can turn them into a better operating rule before the next large change begins.
Start a free stacked PR retrospective board. Add the five columns, share one link with the team, collect cards anonymously, vote on the biggest constraint, and leave with one measurable change for the next stack.
