The backlog refinement session had twelve minutes left and one item to go. “Migrate the notification service.” Five points, no acceptance criteria, an assignee to be named later. Everyone was tired. “We’ll shape it in sprint,” someone said, and the item slid into the release. Two months later, at the quarterly review, that one line had become three stories, a vendor ticket, and eleven days of drift on a date the team had promised in front of the room. Nobody lied at the vote. The team voted on work that didn’t have a shape yet.
A confidence vote at PI planning is not a guess. It is the most concentrated expert judgment your organization produces — the engineers who know the codebase reading the plan and stating, on the record, how likely it is to hold. But a vote can only be as good as the evidence on the table. When an item enters the release half-shaped, the people in the room aren’t judging the work; they’re judging a placeholder. A Definition of Ready exists to stop exactly that. Unready work is the quiet doorway for scope creep, one of the three ways a committed release date slips — the growth was already inside the item. It just hadn’t happened yet.
What a Definition of Ready actually protects
A Definition of Ready is a short working agreement about what an item must have before the team commits to it inside a release: small enough to finish within a sprint, acceptance criteria a tester could act on, dependencies named, sized by the people who will build the thing. The checklists vary — INVEST is the classic — but the acronym isn’t the point. Each unchecked line is a specific place the item can grow after the vote. A story with no acceptance criteria doesn’t stay ambiguous; it resolves its ambiguity in week five, as new scope. Teams that measure scope creep usually find the biggest in-ticket growth came from items that entered the plan unready.
A door policy, not a toll booth
The standard objection is fair: gate “ready” too hard and you have rebuilt waterfall one refinement at a time, with items queuing for sign-offs while the sprint starves. A Definition of Ready is a door policy the team writes for itself, not a stage a PMO enforces. Keep it to one page. Apply it where it matters: the work entering a committed release. The wider backlog can stay rough — scoring a five-hundred-item abyss is its own trap — but the Fix Version you promised a date against deserves items someone has looked in the eye.
The gate narrows the growth. The forecast catches the rest.
Here is the part the checklist articles skip: even a good Definition of Ready doesn’t end scope growth. A migration is always bigger than it looks. The gate narrows the distribution; it doesn’t zero it. Which is why readiness needs a partner on the far side of the commitment. In Release Management, Roadmaps & Product Portfolio for Jira, the release’s scope is baselined when the team commits, and the Monte Carlo forecast keeps re-reading the plan as it changes: every story added, split, or grown after the vote shows up as drift against the committed date — in days, on the 50/85/95% confidence band the team voted against. An unready item that doubles isn’t a surprise at the demo. It’s a reading the week it happens, while there is still room to renegotiate scope instead of apologizing for a slip.
It also has a mirror. The definition of ready vs definition of done question is not either/or: the Definition of Done is the fine print of the confidence vote — it decides how much work a “done” item actually retires from the release. Ready guards the entrance; Done guards the exit. A release with both doors attended is one where the number the team voted stays attached to reality all the way to ship.
A working setup
- Write the Definition of Ready with the team. One page, revisited at retro like any other working agreement. If a line never catches anything, delete it.
- Refine to ready only what enters the committed release. Rough is fine everywhere else — readiness is release-scoped, not backlog-wide.
- Watch committed items weekly for growth. When in-ticket growth and added scope eat the slack between your committed date and the 85% line, renegotiate — before the date moves, not after.
The item you shape in refinement costs the team an hour. The item that shapes itself in week six costs the date — and a little of the room’s trust in the next vote. Keep the door policy human, keep the forecast live, and the confidence your teams vote stays earned. Keep your committed date honest in Jira, or see how scope is tracked against the release in the docs.
Leave a Reply
Your email is safe with us.