The scenario and rollout values below are illustrative, not results from a production release.
A feature flag separates deployment from exposure only if the handoff preserves that distinction. “Implement the new checkout behind a flag” leaves several decisions open: who may deploy the code, who may change the flag, and what evidence is needed before more users see it?
Write those boundaries before assigning the implementation. A developer can prepare a change and return evidence. The release owner still needs a clear decision point.
Start with the flag off
Consider a hypothetical checkout summary that recalculates shipping after a user changes an address. The task is to implement the new summary behind checkout_summary_v2, with the existing behavior retained when the flag is off.
The product owner defines the expected user behavior. An engineer prepares the repository context, tests, and constraints. The runner executes with their own authorized tools and environment. A reviewer judges the implementation, and the release owner authorizes deployment and exposure changes separately.
Neither access to a flag dashboard nor a passing test implies permission to enable production traffic.
Use a brief with separate exit conditions
Feature: checkout_summary_v2
Default: off
Implementation scope:
- Add the alternate summary path behind the flag.
- Preserve the existing path when disabled.
- Do not change payment authorization or order persistence.
Required checks:
- Flag off: existing address-change behavior remains intact.
- Flag on: displayed totals match the approved calculation fixture.
- Flag changes: no duplicate charge or duplicate order request.
- Missing flag configuration: retain the approved safe default.
Delivery package:
Revision, changed files, exact test commands and outputs,
screenshots from the same fixture, known limits.
Implementation acceptance: [named engineering reviewer]
Product acceptance: [named product owner]
Production deployment: [named release owner]
Exposure changes: [named flag owner]
Stop boundary:
Return the reviewed change. Do not deploy or enable production traffic.
This is a task template, not a record of completed checks. Replace the placeholders with real owners and attach actual evidence before acceptance.
Make the staged rollout a separate decision
An illustrative rollout could progress from internal users to 1%, then 10%, then broader exposure. Those percentages are planning examples, not universal recommendations. The release owner must define observation windows, relevant metrics, and rollback thresholds for the actual service.
Require explicit approval at each stage. A quiet dashboard over a short interval may simply mean that too few users exercised the feature. Include a minimum useful sample or a representative manual check instead of assuming that elapsed time proves safety.
For the checkout example, inspect calculation mismatches and failed completion attempts. Also check whether the old path still works when the flag is disabled. Document who may halt the rollout and where that decision is recorded.
Make rollback a behavior, not a slogan
Turning a flag off is only a rollback if the old path can still operate with the state produced by the new one. If a migration or irreversible side effect has occurred, disabling exposure may not restore the previous behavior.
The example deliberately excludes payment and persistence changes to keep the task narrow. If implementation discovers that either must change, stop and revise the brief. Do not stretch a UI task into a transaction-system change without a new review.
A useful rollback rehearsal records the starting state, the disabling action, and the resulting user behavior. An unexecuted runbook is still a plan, even if the commands look correct.
Keep the delivery and the approval connected
Teams that manage work in one system need to preserve the difference between “a runner returned a change” and “the accountable owner accepted it.” Wagglet’s request-to-delivery workflow describes that separation; this brief makes the responsibilities explicit regardless of the tracking tool.
The reviewer should be able to identify the accepted revision, the evidence supporting it, and any unresolved limitation. The release owner should see the same information before approving exposure. If new evidence invalidates the decision, the task history should explain why the rollout stopped.
The flag’s default, the delivery’s acceptance, and the release’s approval are three different facts. Write each one down, assign each decision to a person, and let the implementation handoff end at the boundary you actually authorized.
Top comments (0)