Run the walkthrough after feature-complete, before ship

What it is

The walkthrough window sits after feature-complete and before ship (feature-complete pre-release walkthrough). Feature-complete means the agreed states — primary path, empty, error, loading, permission denied — are reachable in staging, not merely “the branch merged”. Before ship means a change can still enter this release. Activity outside the window may be a review or a patch; it is not this walkthrough.

Too early: missing states look like defects, the log fills with unfinished work, and real intent misses drown in noise. Too late: the same finding is already with users, the fix needs another window, and the walkthrough decays into after-the-fact filing.

Why it happens

Judgment needs a complete object. If empty, error, and permission-denied are still unwired, reviewers cannot tell “not built” from “built wrong”. Most notes from a premature session vanish in later development; the few intent problems left behind sit among expired items, follow-up cost rises, and the team learns to ignore walkthroughs.

A release cut turns mutability off. After the cut, the change rides the next train, which has its own scope, and the finding re-queues. A walkthrough after the cut can no longer spend “we can still change this ship”; it can only spend “later” — and “later” has no force. The window is the only interval where the object is whole and change is still cheap. Calendar position is not courtesy; it is whether the conditions of judgment hold.

Where it stops holding

Continuous delivery with many production pushes a day has no single big release; the window rebinds to “this change is feature-complete” and “before this change hits production”, the same pair of bounds on an hourly clock. A hotfix that only stops a crash and carries no interface intent should not insert a walkthrough that blocks the fix. When clients ship out of sync with the server, each client has its own complete-and-cut; server-first is not “the client is walkthrough-ready”. If feature-complete is quietly redefined as “the happy path clicks through”, empty and error are still missing and the left bound has not been reached.

Applying it

• Write two timestamps into the release checklist: when every agreed state is reachable in staging, and when the package freezes. The walkthrough must sit between them.
• Before the meeting, tick a state table: primary, empty, loading, error, permission denied. A missing cell delays the session; do not “look at what we can”.
• Stamp the notes with the build they compared; if that build is past freeze, mark the record as a post-ship find, not a must-fix for this cut.
• How to check: take the last three walkthroughs and test whether their timestamps sit between “state table full” and “package freeze”. One session held with an incomplete table, or notes aimed at a build already live, means the window rule is not in force.

Related

• Same group: R2.02.1 Walkthroughs compare the build to design intent · R2.02.3 Grade findings by severity instead of demanding every fix
• Adjacent: R2.12 Design–engineering cadence · R2.05 Edge-case delivery completeness
• Search terms: feature complete · pre-release QA · design walkthrough timing · code freeze