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 Advanced Release Planning for Jira 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. Advanced Release Planning 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 Advanced Release Planning free for 30 days — and let the next “small clarification” pay rent in visible days, not a silent slip.
Leave a Reply
Your email is safe with us.