Everybody in the room agreed the ticket was small. Add a filter to the reporting screen. Two points, maybe three. It went into the release, the team committed, and the hands went up.

Three weeks later it is on the demo. The filter works. And the stakeholder says the sentence that costs more than any change request ever will: that is not quite what I meant. The filter needs to persist between sessions. It needs to work on the export. It needs to respect the permission scheme. None of that was ever written down, which is exactly why nobody priced it.

Somebody in the retro will call this a Definition of Done problem. It is not.

They answer two different questions

The two agreements get conflated constantly, and the distinction is simple once you write it out.

The Definition of Done is uniform. It is the same checklist for every item the team touches: reviewed, tested, documented, merged, deployable. It answers is this item finished to our standard? You agree it once and reuse it. Because it applies equally to everything, it never tells you how big any particular thing is. Its failure mode is work that comes back later as rework, which is its own way of eroding a committed date.

Acceptance criteria are per item. They are written fresh for this story, usually with the person who asked for it, and they answer a different question entirely: what does this specific thing have to do before we call it right? Persist between sessions. Work on the export. Respect permissions. Each line is a pass or fail statement about one piece of work.

One is the bar. The other is the boundary. And the boundary is where a release date lives.

Only one of them carries scope

A confidence vote is expert engineering judgment applied to a specific understanding of the work. The room looked at a set of items, understood each one to be roughly a certain size, and committed on that basis. That judgment was sound. It was also conditional on every item actually being the thing the room pictured.

Vague acceptance criteria break that condition quietly. The three-point filter did not grow into an eight-point filter. It was always an eight-point filter. Nobody added anything, so nothing looks like an addition, and the team spends five points it never had.

That is what makes this the most expensive kind of scope movement to catch. Late dependencies announce themselves eventually. Capacity changes show up in a calendar. Scope creep of the ordinary kind at least leaves a ticket behind. In-ticket growth leaves nothing: no change request, no board approval, no negotiation about the date. It is one of the three things that erode a committed release date, wearing the only disguise that makes it invisible on paper.

Why your burn-up stays quiet

Here is the mechanical reason this hides so well. A throughput forecast reads finished items against remaining items. When work expands inside a ticket, the remaining count does not move. The scope line on the burn-up stays flat and honest looking. The only thing that changes is how long each item takes to close, which the forecast reads as reduced throughput.

So the chart tells you the team got slower. Everyone reaches for a capacity remedy, more people or longer hours, because that is what the data appears to say. The team is not slower. The units are bigger. Treating a scope problem as a capacity problem is how a release loses a fortnight before anyone names the cause.

Write criteria the forecast can read

Three working practices keep the boundary honest without adding ceremony.

Make every criterion testable. If a line cannot be answered yes or no by someone looking at the build, it is a hope, not a criterion. Write them with the requester, not after them, because the gap between what was asked and what was heard is where the extra points hide. And when criteria change after commitment, record that as scope movement against the release, not as a clarification. It is the same decision as adding a ticket, and it deserves the same visibility. The Definition of Ready is the door policy that catches most of this before the vote; what follows catches the rest.

What it looks like in Jira

Release Management, Roadmaps, Portfolio PPM & Timeline baselines the release scope at the moment the team commits, then keeps re-forecasting over the team’s real Jira throughput with Monte Carlo simulation. When work expands inside a ticket, the drift is reported the same way every other movement is: in days against the committed date, on a 50/85/95% confidence band the whole room can read.

The team still owns the assumptions. Which throughput window to trust, whose capacity is genuinely in, what belongs in this release, and what “right” means for each item. The app does the arithmetic at Monte Carlo scale and keeps it current, so a committed date carries its confidence instead of standing alone in a field. See how it works in the docs.

Vague acceptance criteria will not stop happening. They can stop happening in the dark. See the drift on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio