Phase 4: Review
How the team reviews Implementation output and routes learning back into the process.
The Review Phase is the team's primary human quality check on what the Implementation Phase produced. Agents generate code faster than a team can absorb it, so the team's understanding falls behind what's been built, and that gap doesn't announce itself. Reviewing agent output every two or three days, rather than letting a week's worth pile up, keeps the team's experienced judgment caught up.
Review also feeds learning back into the process. Some findings become immediate fixes. Others become input for a future Definition Phase, such as a follow-up question, a spec refinement An evergreen description of how a part of the system or experience works. Kept current with actual behavior; when the team wants a change, the spec is updated first and implementation brings the system into alignment. , or a piece of Compounding Work Work that improves the delivery system itself: stronger specs, better examples, agent instructions, review agents, patterns, tooling, and validation paths that future delegations can build on. . Which one a finding turns into depends on product-owner priorities, the project timeline, and the product direction.
Running the ritual
| Step | Activity | Tasks | Who executes |
|---|---|---|---|
| ↻ per item | Demo & explain it | For each completed effort or other substantial piece of work, the developer explains what changed, how it is structured, how it was verified, and what frictions slowed delivery. | Team |
| Probe it together | Ask questions, surface risks and implications, explore alternatives. Repeat until the team has reviewed every completed effort or substantial piece of work that needs team attention. | Team | |
| Exploratory testing | Step back and exercise the iteration's combined output hands-on: end-to-end flows, integration between newly landed pieces, regressions, UX friction. Surface findings for remediation. | SoloCollab | |
| Remediate or scope follow-ups | Break into solo or pair work. Fix low-hanging issues immediately; turn larger issues into follow-up questions, spec refinements, Compounding Work, or tasks for a future iteration. | SoloCollab |
The demo-and-probe pair repeats for each completed effort or substantial piece of work that needs team attention. Once the team has worked through everything, the team breaks off for hands-on exploratory testing of the combined output, then comes back together to fix issues, capture follow-up questions, write spec refinements, or scope the next iteration.
Example: Reviewing the Invite Members effort
The Invite Members effort merged mid-iteration. At the iteration's Review Phase, the team looks at it together for the first time as a finished feature, alongside the rest of the Implementation output.
Running example · Invite Members effort
Demo & explain it (whole team). The developer who built Invite Members walks the team through it. Inviting someone as an editor consumes a seat, inviting someone as a viewer stays free, and the invite table's Pending row moves from sending to sent. The developer explains the decision that shaped the feature, why the seat count is derived rather than stored, and names the friction that slowed the work down. The slow part was confirming by hand, over and over, that invite emails actually went out in staging.
Probe it together (whole team). The team pushes on the parts the demo glided over. What does an invitee see if the admin revokes the invite after the invitee has already clicked it? What happens to a reserved seat if an editor invite simply expires? Someone asks whether two admins inviting into the last seat at the same moment is really handled, and the developer walks through the all-or-nothing seat check that closes it. Any question the team can't resolve on the spot gets written down to settle later.
Exploratory testing (solo or pair). Away from the demo, someone exercises the Invite Members flow against the rest of the iteration's output by hand, inviting an email that already belongs to a member, letting an invite sit until it expires, and inviting up to the seat limit and one past it. The limit holds. Two smaller problems surface, though. The message a user sees at the limit is vague about what to do next, and a revoked invite still shows a stale Pending row in the invite table until the page refreshes.
Remediate or scope follow-ups (solo or pair). Each finding routes to where it belongs. The vague at-limit message is a quick fix, so the team applies it and re-demos the same day. The stale Pending row needs more than a same-day fix, so it lands on the Work Board for the next iteration. The deeper question the probing raised, whether an expiring invite should auto-release its reserved seat, isn't this iteration's call, so it becomes a spec question routed back to Definition. The email-checking friction is a different kind of finding altogether. A one-off bug gets fixed, but a recurring drag like this gets tooled away instead, so the team logs it as Compounding Work for the harness.
Output. The whole team understands what landed. The small fixes are made or scheduled, one open question is back in Definition's queue, and one recurring friction is queued as Compounding Work for the harness.