Requirement change mid-development: edit the spec or file a new task

A change in the middle of development is not an accident, it is the norm. The client saw an interim result, support brought a complaint, something surfaced that nobody knew when the spec was written. The problem is not that requirements change, but that the change bypasses the places where it needed to be taken into account.

At that moment the analyst has two obvious moves, and each is bad in its own way.

Two wrong answers

Always edit the spec

Quick and polite: the document is open, three lines are replaced, everyone knows. Except “everyone” means the people in the thread. Meanwhile the spec stops being what was estimated, and what the tester has already started writing checks against. The text looks as if it had always read that way.

The outcome is recognisable: the developer built to the first version, the tester checks against the second, acceptance turns into an argument, and the argument cannot be settled — the first version no longer exists.

Always file a new task

It looks like discipline; in fact it is a way of not making a decision. The original task goes out in the release knowingly wrong, and the “tail” with the fix lands in the backlog and lives there for a quarter. All that time users work with something already known to be unfit.

The question is not procedure but value. An “always do this” rule is convenient because it removes the need to think. But choosing between an edit and a new task is choosing what goes out in the release, and it should be made by someone who understands why.

How to choose

One main question decides it: does the original version have value without the change. If it can be released and people will use it, the change becomes a new task. If without the change it is useless or harmful, the spec was wrong, and the fix belongs in the same task.

The other signs refine the answer:

The last row is the same three signs that, in the piece on scope boundaries, separate a clarification from new work. A new role, a new state of the data or a second source of truth almost always means a new task, however harmless the request sounds.

If the signs pull in different directions, the main question decides. And if the analyst has no answer to it, it is a question for the product owner, asked directly: “do we release as it was, or wait for the fix”.

If you edit the spec

An edit is acceptable; an invisible edit is not. The difference is one record that stays next to the requirement:

REQ-114   access closes when the subscription expires
  rev. 2    2026-09-18
  was       within an hour
  now       within five minutes
  reason    support complaints, BUG-402
  decided   product owner
  affected  TASK-2071 (in progress)
            test_REQ_114_access_closes_within_hour

Note the last line. The test name carries the old value, and without this record the test would have gone on confirming an hour. This is exactly the break described in the piece on traceability: the change reaches the code and never reaches the check.

The minimum without which an edit counts as unrecorded:

• The old value is kept. Not crossed out in someone’s head, but visible in the text. Otherwise there is nothing to settle an argument at acceptance with.
• The changed acceptance criterion is named explicitly. Not “clarified the logic”, but which condition became what.
• The tester learned it from the ticket, not from the chat. A message in a thread is read by the people in the thread. The ticket is read by whoever does the checking.
• The estimate is revisited, even if it stays the same. “Estimate unchanged” is also a decision, and somebody made it.

If you file a new task

A new task is dangerous not in itself but because the original pretends it never happened. Two links fix that:

1. A line in the original ticket about the split. “Change such-and-such is not included, moved to TASK-2094, decided 18 Sep.” This continues the list of things turned away described in the piece on boundaries.
2. The original is accepted against its original criteria. Not the new ones and not a mixture. Otherwise acceptance turns into an argument about which task is being checked.

One more thing: the new task needs a date, or at least a place in the queue stated out loud. A tail task with no priority is a refusal dressed up as agreement.

A change that went past the analyst

The most common case is not the one where the analyst chooses. It is the one where someone messaged the developer directly, the developer built it, and the spec knows nothing about it.

The sign is simple: the code has moved beyond the text. At the demo the system does something that is in no criterion, and everyone treats it as normal because “that’s what was agreed”.

The cure is not a ban on conversations but a rule: a change does not exist until it is written in the ticket. A developer can accept a request, but implements it after the line appears in the spec. This is not bureaucracy but protection for the developer: otherwise at acceptance their work looks like freelancing.

If the answer to “why does the system do this” is “because someone asked” rather than “because it is written”, the spec has stopped being the source of truth.

A ten-minute check

Take the last closed task in which something changed along the way. Compare the acceptance criteria in the spec with what actually shipped. Every divergence that cannot be explained by a record in the ticket is a change that went past.

What next

An unrecorded change survives into testing, and there the tester finds a divergence between the system and the spec. Then comes the argument: is it a defect, or did the spec simply not say? That is the subject of the next section.