Definition of Ready: When a Ticket Is Ready to Start
By Sebastiaan Jansen · · 7 min read
A definition of ready is a short checklist a ticket has to pass before anyone starts on it. It asks whether the team knows the outcome, the constraint, and the first step. Without one, work stalls on missing access, unclear scope, or a decision nobody made.
Below: the list to copy, an example, and how it sits next to a definition of done.
What a definition of ready is
The team writes it. A ticket that fails stays in the backlog or in triage. Every line is answered yes or no, so "Acceptance criteria are written" works and "The ticket feels clear" does not.
Ready is about starting and done is about finishing. A ticket can pass ready and still fail a definition of done, because tests, review, and release only exist once the work does. Merge the two into one list and it does neither job well.
It is not a specification either. A product requirements document covers the problem, the users, and where the feature ends. The checklist only says this slice is buildable. Putting a PRD on every ticket is too heavy for a bugfix and too thin for a new surface.
The list protects the builder, the reviewer, and the queue. Nobody should find a missing API six hours in, or learn at review that "correct" was never agreed on. Work that cannot start shouldn't be sitting there as "waiting on design."
What to put on the list
Aim for eight to twelve checks someone can read in two minutes:
- Outcome: one sentence on what is true once this ships. If it takes three sentences, you probably have two tickets.
- Acceptance: each check passes or fails without the author in the room. Name the result, the input, and the case that must not break.
- Boundary: what is in, plus one exclusion, so "while you're in there" has nowhere to land.
- Dependencies: design, environments, credentials, linked tickets, and decisions are done or marked not required. "Waiting on legal" with no owner fails.
- Size: it fits the cycle, or you split it before it starts.
- Location: a repo path, a screen, an error, or a source note. A title is not a location.
Write it in the team's own words. Platform work names flags and compatibility, while client work names the environment and the meeting note.
Cut lines that are always true, ignored, or already enforced. An ID is noise. Story points don't say you can start. "A senior approved it" hides a constraint that belongs on the ticket. A design review half the tickets skip exists only on paper, so staff it or remove it.
How the list stays current
A definition of ready that nobody opens at triage goes stale. Keep it wherever the ticket changes state.
Teams that share a backlog often need different definitions of ready. Publish both, because one name can hide two different start conditions.
Once a cycle, keep the checks that caught a real problem and delete the ones no ticket has ever failed.
Three failures repeat. A feature-only list skips bugs and chores: a bug needs steps, an expected result, and an environment, and a chore needs a reason it cannot wait. "Product signed off" stops the builder from naming a contradiction; shared checks beat a sign-off from one role. And treating ready as fully specified makes a copy change wait on a sequence diagram. Ready means safe to start. Later questions are allowed.
Definition of ready in agile planning
A definition of ready in agile planning is the entry rule for the sprint, the cycle, or the ready column. The Scrum Guide requires a Definition of Done and a transparent, ordered Product Backlog. It does not require this rule. Teams add it anyway because a forecast is weak when half the tickets can't start on day one.
Use it at refinement, at planning, and mid-cycle. Each gap becomes a task: write the check, ask the client, or split the story. A ticket that fails isn't a planning candidate. Urgency can reorder the work, but it doesn't lower the bar. Incidents get a short list: the impact, how you will know it is fixed, and who is on it.
The ready stage is a column, and the checklist is how a ticket leaves it. Triage can sit in front of it. A kanban limit fails when that column fills with tickets that bounce back.
Where it sits next to the spec
| Artifact | Question it answers | Typical length |
|---|---|---|
| PRD | Why this, for whom, and what is out for good? | Several pages |
| Product specification | What will the system do? | A long doc |
| Ticket | What slice ships this cycle? | A screen of text |
| Start checklist | Can we start this slice today? | A short list |
A product specification holds shared behavior such as permissions or empty states, so link the section instead of copying it. A requirements traceability matrix follows a requirement through a test to a release. This checklist only covers the front of one row.
A worked example
Support says clients cannot export last month's invoices and asks for a CSV. The problem is real, but the solution is a guess.
Title: Download a CSV of invoices for a selected month from Billing.
Outcome: An account admin downloads one CSV for the month they pick, without going through support.
Checks: March 2026 returns only that account's invoices. Columns are number, issue date, currency, and total. A non-admin does not see the control. An empty month downloads headers only. PDF export, payment retry, and tax fields stay as they are.
Out of scope: a ZIP of PDFs, ranges other than a month, and multi-account exports.
Dependencies: None. Billing already lists a month. No new provider or design file. Use the existing secondary button.
Size: One engineer, one cycle, tests included. No migration.
Origin: the 2 April support thread, two account names, and the Billing route.
All six pieces are there, so it can start. An import with no sample file fails and goes back to one owner. Timeouts on large accounts are a second ticket. Split, then recheck each half.
Who confirms it
Whoever moves the ticket into active work confirms the list. That's usually the engineer, sometimes triage. Product, engineering, and the client fill the gaps, and one person marks it green.
A plan an agent produces from the repository gets the same check before it becomes the build path. The agent can propose checks, but a person marks them true. A fast plan on a vague ticket just ships the wrong change sooner.
With ticket types, triage, and workflow rules, the list can gate the build stage so a failing ticket never enters the cycle. The delivery loop still needs a human to say yes. A pinned checklist or a board policy does the same job. Falrow is one place that loop can live: a call note becomes a ticket, and a person reviews it before work starts.
What it does not fix
A clean start won't rescue a badly cut slice, and it says nothing about priority. It doesn't pay down technical debt; it only blocks debt work nobody can describe. A debt ticket still needs a symptom, a boundary, and a way to tell the paydown worked. If those tickets keep losing to stories, fix the ordering.
Ready to build doesn't mean safe to ship on a Friday, behind a flag, or to every tenant. Release checks belong with the definition of done. The list adds no capacity, and a long cycle time means too much work in progress. What it removes is false starts.
Introduce it in a week
Ask three people what they wish they had known before the last ticket. Turn repeated answers into yes/no lines: one list per type, under ten lines. Leave work already underway alone and apply the list next cycle. Each retrospective, delete one line and add one at most. A check that always fails is an intake problem: put the field on the form, or turn the note into a ticket while the talk is fresh.
"This slows us down." The wait moves to triage, before anyone opens a branch. Bounce-backs already cost that time.
"Small tickets are exempt." They need a shorter list. A copy change is ready when the words, the page, and the locale are written down.
"We have a PRD." Link the section and name the slice. If the PRD is being used as the ticket, nobody has cut the slice.
FAQ
What is a definition of ready in Scrum?
It's a team agreement on when a backlog item can enter a Sprint. The Scrum Guide requires a Definition of Done and an ordered, transparent backlog, not this list. Teams use it so planning only holds work that can start. A failed check means a missed agreement, not a failed ceremony.
How is it different from a definition of done?
One controls entry and the other controls exit. Entry asks whether the outcome, the checks, the boundary, and the dependencies are known. Exit asks whether the change is built, reviewed, tested, and releasable. Every ticket needs both, and a single list trying to do both jobs gets argued about at the wrong time.
Who owns the checklist?
The people who do the work, because they hit the gaps. Product, design, and support write the lines they can satisfy, and whoever pulls the ticket confirms each one. A manager can ask for the agreement but shouldn't rewrite it alone.
Can a bug use the same idea?
Yes, with a shorter list: steps to reproduce, expected and actual behavior, environment or version, and whether a workaround exists. Severity sets the order, but it doesn't waive reproduction. An incident already underway needs the impact, how you will know it is fixed, and who is on it.