Implementation Plans: From Intent to a Verifiable Result

Once you can describe an architectural boundary and shape the work, cut a change into vertical slices, and mark the dependencies between them, the next step is to gather those decisions into an implementation plan: a sequence of work with preconditions, intermediate results, evidence and conditions for proceeding.

A plan does not predict the future, and it does not prove that the chosen design is right. What it does is help the team see what is known, what still has to be checked, how the change will touch the existing system, and how to stop or change direction safely. A good plan can be executed and revisited. A bad one merely creates the impression that every unknown already has an answer.

The service names, booking rules, dates, metrics and results in the teaching examples are invented. They do not describe any real company.

What question a plan answers

An implementation plan answers a practical question: which changes, in what order, on what basis and with which checks will produce the accepted behaviour? It links several different records together, but it does not replace any of them.

Artifact	The question it answers	What it does not settle on its own
Product Requirements Document (PRD)	What problem are we solving, and for whom? What behaviour is needed?	Which files or tables to change
Software Architecture Document (SAD)	Which parts of the system and which boundaries are involved?	Whether every assumption about the current implementation has been confirmed
Architecture Decision Record (ADR)	Why was a particular technical decision taken, and which alternatives were rejected?	The full execution sequence for every change
Implementation plan	What do we change, stage by stage; what depends on what; and which evidence unlocks the next stage?	Whether the requirements are correct, or whether new facts will turn up
Test plan	Which checks will show that the behaviour matches expectations?	Actually running those checks

Suppose the PRD says "a customer can reschedule a booking". The plan still has to answer: what happens to the old slot if the external calendar does not respond; who is allowed to perform the action; how a repeated request avoids creating a duplicate; and how we will notice a partial failure. If the authoritative sources do not answer these questions, do not let a guess quietly become a technical requirement.

The full test plan is the subject of planning checks before coding. A plan may also point to a decision that has not been made yet. That is acceptable as long as the decision has a named owner, a deadline or triggering condition, and a list of the work that waits on it. "Figure it out later", with no one responsible and no stated consequence, is not a controlled unknown.

Gather the inputs first

Before breaking the work into steps, check which sources already exist. Documents are not the only ones that matter: the current code, configuration, database, logs, test environment and the supplier's real constraints are often more accurate than an old description.

Input	What we look for	How to flag a problem
Requirements and acceptance criteria	Expected behaviour, exceptions, permissions, scope boundaries	A contradiction or a missing product decision
Code and tests	Current rules, calls, background processes, compatibility	A conclusion not yet confirmed by a test or by running the code
Application programming interface (API) contracts	Request and response formats, error statuses, consumers	Client versions that may still be active
Data and migrations	Source of truth, constraints, volume, schema history	Whether data has to be moved, and how to check that the move is complete
Infrastructure and access rights	Environments, secrets, queues, network permissions, feature flags	Access that is missing or cannot be granted to whoever does the work
Operations and support	Monitoring, on-call duty, manual recovery, customer requests	Who makes decisions during an incident

You can attach a short label to every important statement: confirmed fact, assumption, decision or open question. For example, "the old booking is cancelled after the new one is confirmed" is a product rule only once the owner of the requirement has approved it. In the example below we explicitly adopt it as a conditional rule for teaching purposes.

Record the code revision, the source of a decision and the date it was checked whenever the plan's reproducibility depends on them. "That's how it works right now" goes stale quickly. A link to a specific file, test, contract version or comment on a requirement gives the next person a way to verify it.

Map the area of impact

A single change can touch more layers than its task title suggests. At a minimum, check:

• the user interface and accessibility;
• API routes and contracts;
• authorisation rules and roles;
• data structure and data life cycle;
• events, queues, schedulers and retries;
• external services, rate limits, authentication and timeouts;
• environment settings, permissions and secrets;
• logs, metrics, alerts and support instructions;
• documentation, client compatibility and release plans.

Do not list every possible file as if it were already known. It helps to separate the confirmed area from candidates still to be investigated. For example: "Confirmed: the reschedule route and the booking service. To investigate: whether the reminder still calls the old calendar identifier." This does not make the plan vaguer; it puts a check in front of code that may turn out to be wrong.

Spell out what is not part of the change as well. "Rescheduling does not change the price", "a completed booking cannot be rescheduled" and "we are not adding refunds" are useful boundaries, provided product rules confirm them. A scope boundary prevents the goal from being swapped out by accident, but it does not give anyone the right to ignore mandatory compatibility, security or recovery.

Plan a verifiable result, not a list of commands

git status, a migration command or a test run can be part of a step, but on their own they do not say why the step is being done. For every stage, name:

1. Result: which state or behaviour should appear.
2. Precondition: what must already be known or ready.
3. Changes: which layer or boundary we touch.
4. Evidence: a test, a comparison, a log, a manual demonstration or a verified decision.
5. Condition for proceeding: what must be true for the next step to be safe.
6. Owner and recovery: who decides if something fails, and what we do with any state already created.

"Update the schema" is too terse a step if, afterwards, nobody can tell who reads the new data, whether the old and new code can run side by side, or what evidence shows the migration is finished. By contrast, "add a compatible structure; run the migration on a copy of data shaped like production; reconcile counts and rules; only then deploy the code that reads it" already has a clear check and a gate.

These gates do not always mean formal human sign-off. A gate can be an automated check or a documented condition. A human decision is needed where product behaviour changes, where a risk is being accepted or where a dangerous operation is performed — not at every technical step.

Worked example: rescheduling a booking

The example's ground rules

Picture a service that stores bookings in a database and synchronises them with an external calendar. In this example the product owner has already approved the following rules:

• a customer can reschedule only their own active, future booking;
• the new time must be available;
• the old booking is kept until the new time is confirmed;
• repeating the same request does not create a second operation;
• after a successful reschedule, the time and the reminders are updated;
• price, payment and cancellation stay unchanged; they are outside this scenario.

This is not a universal policy. In real work you would check it against the contract, the terms of service, current constraints and the product owner. We also assume that an investigation in the test environment confirmed that the calendar lets you reserve a new time first and then confirm or reject it. If that assumption does not hold, see the separate example in When an external service does not support the operation you need.

Step 0. Reconcile the starting state

Result: a map of the current flow, from the customer's request to the calendar entry. Whoever does the work finds the booking-creation route, the owner and status checks, the event types, the reminder process and the relevant integration tests. They also check whether an idempotent-request mechanism already exists (an idempotent operation produces the same outcome if it is accidentally repeated).

Evidence and condition for proceeding: the source of truth for booking status is named; who changes the status, and when, is written down; the test environment reproduces ordinary booking creation. If the code and the requirements contradict each other, the question goes back to the owner of the requirement before implementation.

Step 1. Check the calendar contract

Result: a short technical finding about reservation, confirmation, timeout, retry and cancellation. The check uses a test account with no real customer bookings. The finding includes the request and response, failure codes, limits and a way to recognise a repeat of the same request.

Evidence and condition for proceeding: a predictable retry returns the same result or safely reports that the operation has already been performed; a timeout does not leave it unknown whether a reservation was created. If the supplier offers no reliable way to find out the state, work stops at this decision: record the unknown, its owner, its consequence and the available options. You may not move on to automatically cancelling the old slot on the strength of an assumption.

Step 2. Add compatible storage for the attempt

Result: a separate record of the reschedule attempt, holding the identifiers of the old booking, the target time and the idempotency key, the current state, the external identifier and timestamps. The exact schema is left to an architectural decision made after reviewing the current database. The new code does not invalidate existing rows; the old route keeps working.

Evidence: the migration is run on a copy built from the current structure; the old and new code can coexist; rerunning does not duplicate the attempt. If a table is created, the check must cover uniqueness constraints and the foreign key to the original booking. A sample of the data before and after is kept for comparison.

Step 3. Implement the server-side flow behind a disabled feature flag

Result: the new operation checks the owner, the status, whether the date is allowed and whether the slot is available; creates an attempt with an idempotency key; reserves the target; and marks the new slot as confirmed only after the supplier responds. The old slot is cancelled only after that confirmation.

Evidence: tests show refusal for a booking that belongs to someone else, is completed or is inactive; sending the same request twice does not create two reservations; an availability conflict leaves the old record untouched. Separately, a timeout between reservation and confirmation is reproduced, confirming that a retry first checks the state instead of blindly repeating the side effect.

Step 4. Reconcile state and side effects

Result: a defined, traceable set of transitions for the attempt: requested, reserved, confirmed, failed or needs_resolution. Every transition has observable evidence and someone responsible for it.

Evidence: a test sequence shows that no reminder is sent for the old time once the new one is confirmed; redelivering an event does not create a second reminder; a failure to cancel the old reservation moves the record into a state that support can see. There is an instruction for this kind of partial success: check both identifiers, confirm what the customer sees, and perform a safe compensating action according to the approved rule.

Not every error has to come down to "roll everything back". The external calendar may already have performed an action that cannot be undone atomically together with your database transaction. The plan has to name the real consistency boundary and the path to correct it, rather than promising a transactional rollback where none technically exists.

Step 5. Check the contract with the client and other consumers

The API is documented before the button is wired up. In our hypothetical contract, the response distinguishes "accepted for processing" from "reschedule confirmed". The client does not show success until the server has confirmation of the new time. If the operation is asynchronous, the client sees its state and can come back to it after a page reload.

Evidence: the client, the server and the test contract generator interpret success, conflict and pending in the same way; an unknown field is not treated as a confirmed time. For older clients we do not change the meaning of an existing response without a separately agreed transition.

Step 6. Finish the accessible behaviour and the instructions

Result: the customer sees available times, unavailability and the outcome of the reschedule; the screen works with a keyboard and with assistive technology; support has an explanation for needs_resolution. Events and logs do not contain unnecessary personal data.

Evidence: an end-to-end check covers the happy path, a conflict, a lost network connection and returning to an open attempt. A log review confirms that an operator can find an attempt by its internal identifier and does not have to search for personal data in unprotected messages.

Step 7. Release to a limited audience and decide by signals

The feature flag is off by default. The team first checks the path in an internal environment, then opens it to a limited group of approved customers, and widens access only after an observation period. The size of the group and the length of observation depend on the baseline load, the risk and the support team's capacity; there is no universal percentage.

The signals must be defined before the first switch-on: the share of failed reschedules, the number of attempts in needs_resolution, duplicate reservations, response time, complaints and support workload. Thresholds come from existing service-level agreements and baseline measurements, not invented after an incident. The release owner can see the dashboard and knows who is able to turn the flag off.

Google Cloud describes a canary release as gradually handing part of the infrastructure to a new version, verifying before expanding, and supporting a return of traffic to the old version. That is an example of one platform's mechanics, not a set of universal percentages for every product. Cloud Deploy documentation on deployment strategies, accessed 26 September 2026.

Step 8. Say exactly what recovery means

If the observations cross the agreed threshold, the on-call engineer disables new reschedules and preserves the attempt logs. The code version can be rolled back to the previous one as long as the previous code understands the new table. Attempt data is not deleted automatically: first the external state of every uncertain operation is established. The incident owner decides whether to perform compensation, notify the customer or stop the related queue.

Restoring the old executable is not the same as restoring the data or the external calendar to their previous state. Amazon Web Services (AWS) advises maintaining backward compatibility during transitions, a period in which the old and new logic coexist, and documented emergency rollback procedures. These are AWS's industry recommendations for their own context of database decomposition; the specific steps must be checked against your stack. AWS Prescriptive Guidance: backward compatibility and rollback, accessed 26 September 2026.

A schema migration is its own plan, not a hidden command

Schemas and data outlive application versions. An old process may still be working through a queue when the new code has already been deployed. That is why a dangerous structural change should not be tucked between "update the server" and "check the page".

The expand-and-contract approach might look like this:

1. Expand: add the new field or table without removing anything the previous version depends on. The new element starts out optional.
2. Prepare for both: deploy code that understands both the old and the new data. If data has to be moved, make the move repeatable and measurable.
3. Compare: reconcile counts, a sample of edge cases, time zones and records without a counterpart. If necessary, temporarily read both old and new and compare the results.
4. Switch reads and writes: only once the data and the consumers are ready, switch to the new behaviour; watch for errors and discrepancies.
5. Contract: remove the old structure only after the coexistence period has ended and it has been confirmed that old versions, backup procedures and external consumers no longer use it.

This sequence is not a ready-made recipe for every database. A large backfill can lock a table, a trigger can cause an action to happen twice, and two fields may follow different time-zone rules. The architect has to choose the technique and match it to what the storage can do. The plan should record the sequence and the evidence, not hide the platform's peculiarities behind a fashionable term.

If a migration is not reversible, say so before running it. State the backup, the restore test, the acceptable data-loss boundary, the authorisation for the destructive step and the person responsible. "Roll back the migration" is not an answer if a deletion has already destroyed information, or if the new code has written values that the old schema cannot express.

A bad plan and how to fix it

Suppose local_time holds the booking's local time, and a new utc_time field is meant to store it as Coordinated Universal Time (UTC). The original entry in our invented service reads:

Remove the local_time field, move all consumers to utc_time, check the bookings.

This is not a migration plan. It does not say what the source of truth is; whether utc_time is already populated; how historical values are to be interpreted; which versions of the web app, the mobile client and the background process remain active; whether the migration is safe to repeat; or what to do if some records have no time zone. "Check the bookings" names neither the data nor the expected result. And deleting the field destroys the path back to the previous code.

The rewritten plan:

1. Confirm what the time means. The product owner approves whether local_time means the local time at the place of the booking or the customer's time zone. A developer finds where this rule is currently applied and records examples that cross a daylight-saving transition.
2. Add a compatible field. The migration adds utc_time, which allows empty values. The old code keeps working. Evidence: the previous version runs against the changed schema on a test copy.
3. Move the data repeatably. The script fills only empty values, writes a reconciliation report and leaves a row unchanged if its source time is ambiguous. Evidence: the counts of successfully converted, skipped and conflicting records match the report.
4. Compare reads. A temporary check computes both values for representative time zones, records affected by daylight saving and boundary dates. The product owner signs off on conflicts before the switch.
5. Switch new reads and writes. Deploy compatible code while continuing to write the old field during the coexistence period. Under observation, check errors, discrepancies and background jobs.
6. Remove the old field as a separate change. Only after all consumers have been checked and the rollback window has closed do you stop writing the old field; the field is deleted in a separate migration with the data owner's authorisation. The reconciliation archive remains available.

The intermediate evidence shows whether it is safe to move on. If many records turn out to be ambiguous, the team does not "fix" them at random to stay on schedule: the owner of the requirement decides the rule, and the plan changes with a written explanation.

Checks are evidence for decisions

Checks are spread across the stages. A static type check does not prove that the external calendar cancels the right record; a scenario run against a test database does not prove that the old version is compatible with the new schema.

Check	What it can confirm	What it does not confirm on its own
Function check	A rule for a local set of inputs	The behaviour of the database, network and external service
Integration check	The interaction of several parts in a test environment	Real limits, permissions and customer data
Contract check	That the shape of requests and responses matches what consumers expect	All the business consequences after release
Migration check	Repeatability and the transformation on a specific copy	That a backup can be restored, unless that was tested
Release check	Operation in the target environment and the presence of observability signals	Safety under every future load
Manual review	That an experienced person checked a defined artifact	Anything they did not review or could not see

For every important piece of evidence, keep the revision it belongs to, exactly what was run, the result, its limitations and its owner. "The tests are green", without a commit, the set of checks and the time of the run, makes it impossible to tell a result for the current code from an old run. In this course we do not accept that the number of agents, a small patch size or a successful compilation can stand in for acceptance evidence.

If some checks can only be done by hand — a legal review of wording, say, or an expert security assessment — name that limitation, who will do the check and when. The label "automated" must not quietly vanish as the plan gets retold.

Release plans and recovery plans are related but different

Release answers who will get the change, in what order, which signals let us continue and who will stop the rollout. Recovery answers how to return the service to a safe state after a failure and what to do with data and side effects that have already happened.

Before the first release, write down:

• the current version and the exact artifact being run;
• the enabled reach, and the mechanism to stop it quickly;
• health signals, the source of the baseline and the decision thresholds;
• who is watching, and for what period;
• the condition for widening, the condition for pausing and the action on failure;
• compatibility of the code, the data schema, the queues and external integrations;
• a recovery action that will not create duplicate charges, bookings or emails;
• the source of truth after a partial success, the person responsible and the procedure for contacting support.

If the feature flag only switches off the interface while a background process carries on creating external bookings, it is not a complete kill switch. Check exactly which action it stops. The same goes for rollback: the old version of the program may not understand a new schema or new statuses that have already been written.

When an external service does not support the operation you need

During Step 1 of the main example, the team might discover that the supplier does not support atomic rescheduling and does not allow a new time to be reserved while the old one is still active. In that case the three operations we were counting on — "cancel the old one", "create the new one", "restore the old one" — do not necessarily form a single transaction. After a timeout, the team may not know whether the new entry has already appeared.

The plan must not silently turn this into "add a few retries". First the exact limitation is established in the test environment, along with what is available for looking up state, unique keys, compensation and response time. Then a decision is prepared, with its consequences:

Option	What it preserves	New risk or limitation	Who decides
Ask the supplier for a new supported operation	Automated rescheduling, if the supplier adds the contract	Waiting, with no defined timeline	The product owner and the integration owner
Propose a time, wait for a person to respond, then reconcile the two actions manually	A controlled flow that does not pretend to be atomic	Slower; requires an operational procedure	The service owner
Leave the booking unchanged and suggest the customer contact support	No risk of silently losing the old booking	The product promise becomes smaller	The product owner
Cancel and create in sequence	May free the old slot sooner	The customer may end up with neither slot	Do not accept without assessing the consequences and explicit approval

The decision has to state what promise the product now makes, how the customer will see a failure, which recovery path is available, and whether scope or deadline change. If no safe option is approved, it is the automated slice that stops — its absence is not disguised as "almost done".

This is a contingency: a conditional course of action triggered by a specific observation. It is not the same as padding an estimate by an arbitrary percentage. A condition triggers it, an owner has the authority to make the next decision, and the effect on the goal is recorded.

Shape Up: appetite is a design boundary, not a forecast

In Shape Up, "appetite" means how much time the team considers it worthwhile to spend on an idea; an estimate, by contrast, tries to calculate the cost of a solution that has already been designed. The authors describe this as "time first, then design" and as working with fixed time and variable scope. It is useful when whoever placed the bet has agreed on what can be cut if difficulties arise; it does not give the person doing the work the right to remove mandatory requirements on their own. Shape Up, "Set Boundaries", accessed 26 September 2026.

For booking rescheduling, for example, you might set aside a limited window to check the supplier and build one useful scenario. If safe automatic rescheduling turns out to be impossible, the team can open only an internal manual process, or come back with a changed solution. What it cannot do, within an unchanged product scope, is simply drop the requirement that the old booking be preserved.

In Shape Up practice, the Hill Chart helps distinguish work where the approach is still being figured out from work where execution is already clear. In text, the same idea can be captured without the chart:

Area	State of knowledge	Next useful action
Calendar contract	Still going uphill: unknown whether reservation is safe	Run a test operation and record the possible responses
Table expansion	The approach is clear but not yet applied	Prepare the migration and the evidence of compatibility
Failure after confirmation	Some rules are known; compensation needs a decision	The service owner approves the support action

A Hill Chart shows how far an unknown has been resolved. It is not a percentage of finished code and not a precise schedule estimate. The Shape Up authors themselves write that an imagined "I already know how" is not enough: the approach has to be validated by real work. Shape Up, "Show Progress", accessed 26 September 2026.

The method has a specific context: Basecamp's bets and cycles. Do not transfer it mechanically to a team with regulatory obligations, an external deadline, or a system that cannot safely be stopped. Shape Up's circuit breaker — the project's built-in safety cut-off — by default means not continuing a failed bet without rethinking it. It is neither an instruction to abandon a critical incident nor an obligation to finish a fixed scope at any cost. Shape Up, "The Betting Table", accessed 26 September 2026.

Small batches and coordination

DORA (DevOps Research and Assessment) describes small batches as a way to get feedback faster, test hypotheses and fix problems earlier. In DORA's guidance, a batch should be independent enough to be verified on its own; collecting many small pieces into one large, late delivery defeats the purpose. The source also cautions that generating large amounts of code quickly with artificial intelligence makes review and integration harder. These are DORA's findings from its own research programme, not a guarantee that every small commit will improve any project. The book Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren, Jez Humble and Gene Kim presents research on which organisational and technical practices are associated with software delivery performance. We use it as research context, not as a guarantee of a causal effect for any individual plan. IT Revolution, Accelerate, accessed 23 September 2026. DORA, "Working in small batches", accessed 26 September 2026.

For a plan, this means: first build and verify a thin but useful interaction, connect the boundaries early, and add the rest of the behaviour in measurable steps. A small number of changed lines is not a small release risk if all the risks are concentrated in a single migration at the end.

In the second chapter of The Mythical Man-Month, Frederick P. Brooks Jr. examines the limits of trying to speed up late software work simply by adding people. A published excerpt from Robert L. Glass's book restates this argument in terms of the time needed to bring newcomers up to speed and the growing complexity of communication. For a plan, this raises a practical question: who will hand over context, review the pieces and merge them? This is a historical observation about human teams, not a measurement of how productive modern agents are. The publisher's page for Brooks confirms the bibliography and the chapter title; the details about onboarding and communication are given here as Glass's summary, not as a direct summary of Brooks's full chapter. Brooks, publisher's page; Glass, "People," Fact 3, accessed 23 September 2026.

When a plan involves parallel workers, name the shared contracts, the order of integration and the person who brings the results together. Hand out separately only what can be verified without a hidden decision from another worker. If all the parallel branches end up waiting on one person, the queue for review or integration can push back the calendar finish date; that is a resource constraint of the actual plan, not automatically a new edge of logical dependency.

Planning in Codex and Claude Code: an aid, not a guarantee

An OpenAI Developers article dated 23 February 2026 describes a native planning mode in Codex that helps form a sequence of steps to review before any changes are made. It also describes the loop for a long task: plan, make changes, check the result, fix, and update the state. This is a product description and an example of how to use it; it does not prove that a generated plan is complete or that it matches a particular team's policies. OpenAI, "Run long horizon tasks with Codex", accessed 26 September 2026.

Anthropic's Claude Code documentation describes Plan mode as a mode in which the tool reads files and proposes a plan without editing anything until it is approved. That is a restriction on changing files, not a check on the accuracy of the analysis or an approval of product decisions. The contract for an individual agent is covered in agent task contracts; it specifies the rights and duties of a single worker and does not replace the plan for a system-wide change. Claude Code, "Plan before editing", accessed 26 September 2026.

A practical prompt can ask the agent first to name the sources of the requirements and the code version, separate facts from assumptions, identify the consumers of the data, lay out the dependencies and name the evidence for each stage. Ask it separately to flag irreversible steps and the conditions for pausing. Then a person checks that the agent has not invented existing routes, permissions, table names or supplier capabilities.

An agent's plan is a draft artifact. It does not replace a PRD, an ADR, an agreed contract, an architecture review, authorisation for a dangerous action or actually running the required checks. Keep decisions and sources next to the work, not only in the chat history, which the next person may not be able to see.

A GitHub example: criteria, implementation and delivery

Issue ivanviragine/wade #515 describes a failure after a planning session finished: the parent process received a file-access error and wrongly reported that the artifact was missing. The issue required the code to distinguish a missing file from a read permission error, to preserve the original working tree for recovery, not to change the external issue during a failed build, and to rerun the checks once access was restored.

The linked pull request (PR), PR #516, contains the problem, the required behaviour and the acceptance criteria, plus a summary of the implementation. The summary describes typed strict reading of state, preservation of the inaccessible working tree, and a recovery command, wade plan --recover, which rechecks binding, completeness, exact content, review and validity before changing the supplier's state. The PR author reports 4,446 tests passing, 180 targeted tests passing, and a review with no findings requiring action on a specific revision.

Comparing these shows three distinct levels:

Level	What this example shows	What can be claimed
Intent and criteria	An access error must not look like a missing file; the artifact is preserved; recovery is rechecked	This is the behaviour requested by issue #515
Implementation and report	The PR contains changes to code, tests and instructions and a description of recovery; the author states the results of the checks	The PR branch attempts to meet the criteria, and the report states which checks were run
Delivery	PR #516 was merged into main on 25 September 2026; this confirms integration into the repository, not deployment to users	It can be claimed that the code is merged; it cannot be claimed that it was deployed

A merge is a fact about integration, not an independent verification of the author's report. Without reproducible commands and a revision, the test results remain the author's statement.

This is a good example for planning precisely because the criteria, the code, the checks and the PR status can be set against each other. But it is not an independent audit of the author's own test results. The issue and PR were checked on 26 September 2026; the text keeps merging separate from release, because the state of the page and any subsequent deployment may change.

The lesson for your own plan is simple: the status "code ready" does not equal "passed verification", "merged", "released" or "observed working for users". Each of these claims needs its own evidence.

How to change a plan without erasing history

A new fact can change the order of work, the estimate, the scope or the architecture. Write down:

1. exactly what was observed, and where this is confirmed;
2. which assumption or decision no longer holds;
3. which dependencies, users, risks and evidence are affected;
4. which options are available, and who can choose between them;
5. exactly what changed in the plan, and from which revision;
6. whether parts already finished need to be checked again.

Do not rewrite the old version as if the team had always known the new fact. Keep a brief decision log: "On 23 September a check against the test calendar showed that a timeout does not return the reservation identifier; so we first add a state lookup by idempotency key, then change the retry flow." This lets the team and any reviewer tell new knowledge apart from an execution error.

If a change affects the goal or the risk, agree the plan with the decision owner. An engineer may propose reducing scope or changing technique, but must not unilaterally drop legally required behaviour, data protection or an agreed outcome.

The minimum record you can hand to someone else

A written plan can be shorter than this unit. A handoff is sufficient if the next person can tell facts from open questions and carry out the steps without guessing at critical policy.

Field	Example entry
Goal and boundary	The customer reschedules their own future booking; price changes are out of scope
Sources and revision	Links to the acceptance criteria, the ADR, the base branch and the relevant tests
Facts / assumptions / decisions	The supplier confirmed reservation in the test environment; the timeout needs a separate check
Stages and dependencies	Once the contract is agreed, the compatible migration and the client work start in parallel; the server flow uses the finished migration; the pilot starts after integration and verification of both parts
Evidence for each stage	Contract check result, migration report, retry tests, pilot observations
Stopping and recovery	An unknown external state moves the attempt to needs_resolution; new attempts can be switched off
Decision owners	Product rule: the product owner; partial failure: the on-call engineer together with the integration owner
Known limitations	The code version can be rolled back separately; an external record that was created needs reconciliation
Plan history	Date, reason for the change, what was reordered or narrowed

Not every small fix needs a multi-page document. The more systems, data, permissions, irreversible actions and unknowns are involved, the more context has to survive alongside the work. The minimum record is not a template for bureaucracy; it marks the line at which responsibility is handed over.

Summary

An implementation plan connects the desired behaviour with a sequence of changes and the evidence for them. First the requirements, code, data, contracts and environment are reconciled; contradictions and assumptions stay visible. The area of impact covers not only the screen and the server but also the consumers of the data, permissions, background processes, external services and support.

Every significant stage has a result, a precondition, evidence, a condition for proceeding and someone responsible. Schema migration, compatibility between old and new versions, release, observation and recovery are each described separately. When a new fact appears, the plan changes with a stated reason and consequences, without rewriting the history of the uncertainty.

Shape Up helps you think about time appetite and unknowns; DORA's research, about shorter batches and feedback; Brooks's experience, about the cost of coordination. None of these ideas turns a deadline into a guarantee. A coding agent's planning mode can suggest a path, but on its own it will not confirm a product decision, compatibility, data correctness or readiness for release.

Sources and further reading

1. Basecamp, Shape Up, Chapter 3: Set Boundaries, no update date; accessed 26 September 2026. Definition of appetite, how it differs from an estimate, and the boundary of fixed time and variable scope.
2. Basecamp, Shape Up, Chapter 8: The Betting Table, no update date; accessed 26 September 2026. Context of betting on a bounded cycle and the circuit breaker; Basecamp's practice is not presented as mandatory for all teams.
3. Basecamp, Shape Up, Chapter 13: Show Progress, no update date; accessed 26 September 2026. The Hill Chart as a way to show unknowns, movement towards a defined solution, and completion.
4. DORA, Working in small batches, page last updated 8 December 2025; accessed 26 September 2026. Arguments about feedback, verifiable batches, AI-assisted work and the risk of changes assembled late.
5. AWS Prescriptive Guidance, Migrating business logic from the database to the application layer, no update date on the page; accessed 26 September 2026. Advice on compatibility while versions coexist, feature flags and recovery procedures in the context of AWS database decomposition.
6. Google Cloud, Use a deployment strategy, page last updated 24 September 2026; accessed 26 September 2026. Mechanics of a gradual canary release and rollback support in Cloud Deploy.
7. OpenAI Developers, Run long horizon tasks with Codex, article dated 23 February 2026; accessed 26 September 2026. Describes Codex's planning mode and working loop as a product characteristic and a vendor recommendation, not an independent assessment of plan accuracy.
8. Anthropic, Claude Code: Plan before editing, current Claude Code documentation; accessed 26 September 2026. Describes plan mode as reading and proposing steps before permission to edit is granted; not evidence that a generated plan is correct.
9. ivanviragine/wade, Issue #515 and Pull Request #516, checked 26 September 2026. The issue defines the criteria, the PR describes the implementation and reports on checks, and the GitHub API record confirms the merge into main on 25 September. Test results are as reported by the author; the source does not confirm a release to production.
10. Addison-Wesley Professional, The Mythical Man-Month: Essays on Software Engineering, second edition, published 2 August 1995. The publisher's page lists the contents, including the title of the second chapter; the full text of the chapter was not read for this research.
11. Robert L. Glass, Facts and Fallacies of Software Engineering, "People," Fact 3, excerpt published on InformIT on 22 November 2002; accessed 26 September 2026. Restates Brooks's law and names the time needed to bring new people up to speed and the added complexity of communication. Used as a secondary account, not as a primary source.
12. IT Revolution, Accelerate: The Science of Lean Software and DevOps, book by Nicole Forsgren, Jez Humble and Gene Kim, published 2018; publisher's page accessed 23 September 2026. Used to identify the book and its research context; the specific practices discussed in this unit are supported by the current DORA page.

Limits of these conclusions. Shape Up and AWS describe their own methods and contexts. DORA reports associations between practices and outcomes within its own research programme; this does not guarantee the outcome of any individual feature. The Codex and Claude Code documentation are sources on the behaviour of specific products. PR #516 was merged into main, but its tests and review are cited from the author's report and do not confirm deployment. The booking example is invented; all its product rules are conditions of the exercise, not facts about a real service.