← All resources
Estimation
11 min read

Ready to estimate is not a finished spec.

Name the fact that would change the size. Then vote. A checklist that demands finished screens before anyone may estimate is a stage gate.

See Story Studio
The sticker outlives the room

Planning poker is on the calendar, so the title gets a number. "Improve validation" becomes a five. The fact that would make it a thirteen never gets written down.

That five is now the plan. Next week nobody can remember what the room was unsure about. They argue with the sticker.

The Scrum Guide of November 2020 is still the official text. It does not define a Definition of Ready. An item is ready to select when the team can finish it in one sprint, usually after refinement has added a description, an order, and a size. This page is that test. It is not a specification, and it is not a brief for a coding agent.

The number arrives before the question

Four habits put a size on work the team cannot yet see.

How a guess picks up a story point

The mockups are the toll

Nobody may estimate until every screen is designed. Mike Cohn, updating his note on 28 June 2023, calls a rule like that a stage gate: one activity must be finished before the next may start. Design and the estimate stop overlapping.

The title gets a number

"Improve validation" is estimated because the session has to produce something. The fact that would double the size — the public API must stay, or it may change — is still in someone's head.

INVEST is a rubber stamp

The item says "as a user" and has a test sentence, so the checklist says ready. Atlassian's Definition of Ready page treats those six letters as the criteria. The team still cannot say what would move the number.

Ready is confused with done

Definition of Done is a Scrum commitment, and it describes the Increment. A backlog item is not an Increment. Finishing the specification is a different job from being able to size the change.

If you cannot say what would change the size, you are not estimating. You are decorating a guess.

A ticket can pass this test and still be empty as a brief for a coding agent. That gate is a different article: A Jira issue is the agent's brief. Ready it first.

Enough is a size, not a specification

Ian Mitchell, on Scrum.org, 24 August 2017, put the stopping rule in one place. Refinement has gone far enough when the team can estimate the item and it is small enough to plan into a sprint without another split. More than that is waste. Less is not enough.

Cohn's rewrite is the same idea applied to design. Not "detailed mockups of all new screens before we start." If the story needs significant new screens, rough mockups have been started, and they are far enough that the team can close the open questions during the sprint. The rule becomes a guideline. Work can overlap.

I stop at three lines. The outcome, in one sentence the team can repeat. The fact that would change the size, written on the item. A yes that it fits one sprint, or a split before anyone votes. The four lines an agent needs — outcome, exclusions, proof, repository — belong to the other article. Acceptance criteria that still catch a green suite doing the wrong job belong to a third. Neither is this test.

Name the fact that would move the number. Then estimate.

Outcome in one line. The assumption that would change the size. Small enough for one sprint. Miss one, and there is nothing to vote on.

Three ways a number gets onto the item

The checklist, the thin ticket, and the named assumption all produce a story point. They do not protect the same thing.

A

A checklist gate

INVEST, finished screens, complete acceptance criteria, closed dependencies. Then, and only then, may the team vote.

B

Vote the thin ticket

The conversation is the refinement. People find the holes while the cards are up. The number is what remains after the meeting.

C

Name what would move the number

One outcome line, one assumption that would change the size, and a split if it will not fit the sprint. Then vote. Designs may be rough.

Option A: the checklist gate

The item may be estimated only after a list of preconditions is complete. Atlassian's page makes that list INVEST. Many teams add finished screens and a closed dependency list.

What the bouncer checks
  • The item must be independent, negotiable, valuable, estimable, small, and testable before a vote is allowed.
  • Screens the story touches are fully designed.
  • External dependencies are closed.
  • Acceptance criteria are written out in full.
Where a gate earns its keep
  • A vendor or another team that has already missed stays out of the sprint. Cohn keeps that one as a rule, not a guideline.
  • A size cap stops a story that cannot finish inside the sprint from being pulled in on optimism.
Where the list becomes the work
  • "Estimable" is circular if the team is forbidden to estimate until the list says the item is estimable.
  • A finished-design rule stops concurrent work. The sprint becomes the phase after specification.
  • The audit looks healthy while the team still cannot say what would change the size.

A checklist is a bouncer.

It does not know which missing fact would move the number. It only knows whether the form was filled in.

Option B: vote the thin ticket

The title goes into the session as it stands. The spread in the votes is the refinement. Whatever number the room settles on is written back to the tracker.

What the session actually does
  • The title is read out. The description, if any, is skimmed.
  • People vote. The high card and the low card talk.
  • The room picks a number so the meeting can end.
  • The assumption that produced the spread stays in the conversation.
Where the meeting is the spec
  • A room can repair a thin ticket. That is what a refinement conversation is for.
  • Nobody waits on a mockup that is not needed to see the size.
Where the sticker wins
  • Next week the assumption is gone and the five remains. People argue with the number.
  • A wide spread that gets averaged is not an estimate. It is a truce.
  • The same fog is sized again at the next session, often as if it were a new item.

If the number sticks and the assumption does not, you estimated the meeting.

The work is still the title.

Option C: name the fact, then vote

Mitchell's stopping rule, with Cohn's guideline instead of a finished design. The item carries the sentence that would invalidate the number.

Two rules side by side: all screens designed before anyone estimates, struck through, and rough screens far enough to close the open question in the sprint
Three lines, then the cards
  • Write the outcome in one line the team can repeat.
  • Write the fact that would change the size. If the public API must stay, say so. If a screen is still a sketch, say what about that sketch would move the number.
  • If it will not fit one sprint, split it before the vote.
  • Then estimate. Leave detailed design, and the agent brief, for their own gates.
Where the number can be thrown away
  • The next question is on the item. When that fact changes, the five is obviously stale.
  • Refinement stays concurrent. Rough screens are enough when the open question can be closed in the sprint.
  • The test fits in the session. It does not need a workflow status called Ready.
Where it still fails
  • Someone has to write the assumption. A title with a blank second line is option B again.
  • The team can name a trivial fact and hide the real one. The bar is only as honest as the sentence.
  • Passing it does not make the item safe to hand to a coding agent.

This is the default.

The checklist and the thin ticket are what you are already doing when that second line is missing.

What each choice actually protects

All three can end with a story point on the item. Only one keeps the reason next to it.

QuestionA. ChecklistB. Thin ticketC. Named fact
The team can produce a numberOnly after the list is completeImmediatelyOnce the assumption is written
The number survives the next questionOnly if the list happened to ask itOften no. The assumption left with the meetingThat question is the gate
Refinement stays concurrentNo, if a rule demands finished design firstYesYes. Guidelines, not a 100 percent gate
Distinct from Definition of DoneCollapses into "the spec is finished"Ignores bothA sizing test only
Distinct from the agent briefStarts copying fields the other article ownsLeaves the issue empty for both jobsStops at the size

The team can produce a number

A. Checklist

Only after the list is complete

B. Thin ticket

Immediately

C. Named fact

Once the assumption is written

The number survives the next question

A. Checklist

Only if the list happened to ask it

B. Thin ticket

Often no. The assumption left with the meeting

C. Named fact

That question is the gate

Refinement stays concurrent

A. Checklist

No, if a rule demands finished design first

B. Thin ticket

Yes

C. Named fact

Yes. Guidelines, not a 100 percent gate

Distinct from Definition of Done

A. Checklist

Collapses into "the spec is finished"

B. Thin ticket

Ignores both

C. Named fact

A sizing test only

Distinct from the agent brief

A. Checklist

Starts copying fields the other article owns

B. Thin ticket

Leaves the issue empty for both jobs

C. Named fact

Stops at the size

Estimate it, or do not

These are the rules I would put on the wall of the refinement session. The Guide will not give you a longer list.

  • If the team can say the outcome in one line, name the fact that would change the size, and the item fits one sprint, then estimate it.
  • If they cannot name what would move the number, then do not estimate. Ask, or split. A finished mockup does not replace that sentence.
  • If the story needs significant new screens, then rough mockups far enough to close the open questions in the sprint are enough. A rule that every screen is fully designed first gets rewritten.
  • If the item depends on another team or a vendor that has already missed, then leave it out of the sprint until that dependency is actually done. That one stays a rule.
  • If the item is ready to estimate and someone wants to assign a coding agent, then stop. The next gate is outcome, exclusions, proof, and the repository.
  • If the estimate is in and the risk is a green suite that misses the job, then the criteria article applies. This page does not write those criteria.
  • If the sprint is a scramble to understand work the team already pulled, then review the bar with the people who do the work. Mark Cruth, on Atlassian's page: the Definition of Ready is created for the team, by the team. It is not a Jira status.

Where these claims come from

  • The Scrum Guide, November 2020

    Still the official current version. No Definition of Ready. An item that can be Done in one sprint is ready for selection in Sprint Planning, usually after refinement adds description, order, and size. Definition of Done is the commitment, and it applies to the Increment.

  • Ian Mitchell, Walking Through a Definition of Ready, 24 August 2017

    Enough refinement has been done when the team can estimate the item and it is small enough for a sprint without another split. More than that is waste. Less is not enough.

  • Mike Cohn, The Dangers of a Definition of Ready, updated 28 June 2023

    A rule that something must be 100 percent finished before the item enters the iteration is a stage gate. Prefer guidelines. His rewrite of the mockup rule is the one used here. A dependency on a team or vendor that has already missed can stay a hard rule.

  • Atlassian, Definition of Ready

    Equates a Definition of Ready with INVEST and with work that is fully understood before it begins. That is the checklist this page refuses to copy. Cruth's line is the part worth keeping: the bar is created for the team, by the team, and it needs another look when a sprint is a scramble to understand the work.

  • Scrum Alliance, Definition of Ready vs Definition of Done

    A Definition of Ready is optional and outside the Scrum Guide. Definition of Done is part of Scrum. Do not let a sizing test turn into a second Definition of Done.

Write the fact. Then vote.

The Guide will not hand you a Definition of Ready. It will tell you an item is ready to select when the team can finish it in a sprint.

The practical test before a vote is smaller than a checklist and stricter than a title. What would change this number? Write that down. Then estimate.

Leave the agent brief, and the proof that the job was actually done, to the articles that already own them.

If the next step is handing the text to a coding agent: A Jira issue is the agent's brief. Ready it first.

If the estimate is in and the risk is a green suite that misses the job: AI can pass the tests without doing the job.

Get the backlog item ready before you estimate it

Acceptance criteria and a ticket the team can build.

See Story Studio