Nobody on the team asked for a new feature. That’s what makes this story worth telling. The ticket was three weeks old and everyone liked it: “Export compliance report to CSV.” Sized, refined, committed at PI planning. Then, in a Wednesday refinement session, someone from the stakeholder side added (helpfully, reasonably) “when we said the standard fields, that obviously includes the audit-trail columns. And legal will want the retention flag in there.” No new ticket was filed. The backlog count didn’t move. The release scope, officially, didn’t change. And the odds of shipping on the committed date got quietly worse.

That’s requirements creep: the slow growth of what committed work means, rather than how many work items there are. Its louder sibling, scope creep, arrives as new tickets you can point at. Requirements creep grows inside tickets you already voted on: acceptance criteria multiply, edge cases become table stakes, “done” gets bigger. Item counts and burndown charts don’t register it, which is exactly why it moves committed dates so effectively.

Your vote was right about the requirements you had

At PI planning, your team’s confidence vote wasn’t a guess. It was expert engineering judgment applied to the requirements as the team understood them that day: which throughput history to trust, whose capacity was real, what each committed item actually involved. The team validated that evidence and committed with its eyes open. Requirements creep doesn’t prove that judgment wrong: it swaps out the requirements underneath it. The vote stays on the wall, recorded at four fingers of five, while the thing it was voting on grows a new shape one “clarification” at a time.

The stealth variant of the first killer

We’ve written about the three things that erode a committed release date after the vote: scope creep, dependencies surfaced too late, and capacity changes. Requirements creep is the first killer in camouflage. Ordinary scope creep at least leaves footprints: a new issue lands in the Fix Version, and a delivery lead can see it and challenge it (it rarely waits for the next PI planning). Requirements creep enters through conversations, comment threads, and review feedback. Each ask is individually reasonable. None of them looks like a change request. What changes is the evidence on the ground: cycle times stretch, throughput sags, stories bounce back from review, and nobody can point at a cause, because the ticket list never changed.

Make the clarifications show up in days

You can’t ban clarifications: half of them are genuine discovery, and pretending requirements never evolve is how teams ship the wrong thing on time. What you can do is make their cost visible while there’s still time to act. That starts with treating the scope you committed at the vote as a baseline, and everything after it as measurable drift.

This is where Release Management, Roadmaps, Portfolio PPM & Timeline does the arithmetic nobody should be doing by hand. It continuously re-forecasts the release against your team’s live Jira throughput (Monte Carlo, thousands of simulations per run) and holds the result against the committed date with a 50/85/95% confidence band. When “clarified” work starts stretching cycle times and dragging throughput down, the forecast moves, and the erosion shows up in days against the committed date, while the item count still insists nothing happened. Your team keeps owning every assumption: which throughput window reflects reality, whose capacity counts, what’s genuinely in scope. The app keeps the reading current.

Days are what turn a vague unease into a renegotiation. “The release feels heavier” starts an argument. “The committed date has lost six days since the vote, and the drift began the week the audit columns arrived” starts a scope conversation, with a MoSCoW cut-line ready for deciding what moves below the line, before the date slips rather than after.

Keep the vote live

A confidence vote is a snapshot: expert judgment, honestly given, on the requirements the team had that day. Release Management, Roadmaps & Portfolio keeps it live, so the day the requirements quietly outgrow the vote, you see it, attributed, in days, with time to act. See how the app tracks scope, dependencies and capacity against a committed date in the docs, or try Release Management, Roadmaps & Portfolio free for 30 days, and let the next “small clarification” pay rent in visible days, not a silent slip.

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