A Ticket Can Go Stale While You're Still Building It

A piece of work bounced back from testing this week for a completely unremarkable reason: by the time it was finished, the requirement it had been built against wasn't the current one anymore. Nobody had done anything wrong. The person building it had followed what was written down when they started. Somewhere in between, the requirement moved, and the first place that mismatch became visible was testing, days after the drift actually happened. That gap, between when a requirement changes and when the person relying on it finds out, is the actual cost. The change itself is nearly always cheap.

It's worth being precise about why testing is the expensive place to catch this, because it's tempting to treat it as a testing success story. Testing did its job. But testing only sees the finished artefact, not the history behind it, so by the time it flags a mismatch, all the effort of building against the wrong version has already been spent. Rework at that point means redoing the analysis, redoing the implementation, and often redoing it under more time pressure than the first attempt had, because now there's a bounced ticket sitting visibly on a board with someone's name against it. Compare that to the same drift being noticed on the day it happened: a two-line message, a five-minute conversation, and the build continues on the current version instead of the old one. Nothing about the underlying change got smaller. Only the distance between the change and the discovery did.

This is a communication-latency problem wearing a process costume, and it's worth naming it that way because the instinctive fixes usually attack the wrong layer. The instinct is often to tighten process — better sign-off gates, more thorough requirement reviews before work starts, a rule that nothing gets picked up until it's been checked twice. Those things help at the start of a ticket's life. They do nothing for a requirement that changes on day three of a five-day build, because the review already happened and nobody re-runs it unprompted. The actual exposure isn't at the start or the end of the work, it's in the middle, during the stretch where a document keeps evolving somewhere else while a person is heads-down building against whatever version they last read.

What struck me about the conversation where this came up was the half-joking suggestion someone made: point an AI tool at the requirement source and have it flag when something changes underneath a ticket that's already in flight. Said lightly, as a throwaway line, but it's a genuinely correct diagnosis of where the leverage is. Nobody needs an assistant to build the feature better. What's actually missing is a narrow, unglamorous watcher whose only job is noticing that a document changed after someone started relying on a snapshot of it, and saying so immediately rather than letting the mismatch surface downstream. That's a much smaller and more tractable problem than "write good code," which is probably why it gets suggested as a joke and then not built — it doesn't feel impressive enough to be worth the effort, even though it would have saved exactly the rework that just happened.

There's a useful discipline in noticing when a proposed AI use case is boring rather than dismissing it for being boring. A model that can hold a conversation and generate a screen is more fun to talk about than a script that diffs a requirements doc once an hour and pings the ticket owner when something moves. But the diff script is the one that actually closes the loop that caused this particular rework, and it doesn't need any of the judgment or creativity that makes the flashier use cases risky. It needs to notice a change and tell the right person. Commercially, that's the kind of automation that's worth building precisely because it's cheap and narrow — an afternoon of scripting against whichever requirement-tracking tool a team uses, set against a recurring cost of rebuilt work every time drift goes unnoticed for a sprint instead of a day.

The pattern generalises well past ticket tracking, and it's worth watching for it anywhere one party is working from a frozen copy of something the other party keeps editing. A crosswalk file built from a source system that's still being amended. A pricing sheet quoted to a client while the underlying rate card changes upstream. A contractor building to a drawing while the architect is still revising it. In every case, the person holding the frozen snapshot has no way of knowing it's gone stale unless someone either tells them or they think to re-check, and re-checking is exactly the habit that erodes under deadline pressure, which is precisely when it matters most. The party best placed to prevent the wasted effort is whoever owns the source of truth, because they're the only one who knows the moment it changed. Putting the burden on the person downstream to keep re-verifying a document they have no reason to suspect has moved is asking them to solve a problem they can't see.

None of this argues for treating every requirement as fragile or wrapping every ticket in change-detection machinery it doesn't need. Most short-lived work finishes before anything upstream has a chance to move, and building a notification system for a two-hour task is its own kind of waste. The judgment call is about how long a piece of work sits open against a document someone else can still edit, and how expensive it would be to find out late rather than early. For anything spanning more than a day or two, on requirements that genuinely evolve — which describes a lot of real delivery work, not the tidy version where scope is frozen the moment a ticket is picked up — a small, boring signal that says "this changed while you were working" is worth more than another round of upfront review ever will be. The review happens once, at the start, when the least is actually known. The drift happens later, quietly, while everyone's attention is elsewhere, and the only defence against it arriving as a surprise is something that's actually watching while it happens.