Definition of Ready: What Work Needs Before It Starts
Updated Oct 14, 202610 min read
A Definition of Ready is a shared set of conditions used to evaluate whether a work item has enough clarity to begin. Atlassian describes it as a way to assess work before a team starts it. In Scrum-oriented practice, teams may apply readiness conditions before pulling a Product Backlog Item into the Sprint Backlog.
Definition of Ready is a team working agreement. It is not an official Scrum artifact or mandatory commitment, and a team can work without one.
The useful version is short. It catches missing context before execution begins, without demanding a flawless brief or forming a small committee devoted to checkbox inspection. The practical goal is to keep a task or issue beside the page context, owner, unresolved decisions, and next step needed to begin responsibly.
A Scrum team may use readiness conditions to discuss whether a Product Backlog Item can responsibly enter the Sprint Backlog. Those conditions might cover available context, dependencies, or other information the team repeatedly needs before starting.
Scrum.org explains Definition of Ready as an optional practice rather than an official Scrum artifact or commitment. An experience report from teams at Cisco framed it as simple team rules that help people remember what needs attention before development begins.
The same idea can help with marketing deliverables, operational changes, research tasks, and product issues. In each case, readiness keeps execution time from turning into assignment reconstruction. A person should be able to find the reason for the work, see who owns the next move, understand what remains open, and take a sensible first step.
A ready item has enough information for someone to take a responsible first step. Complete certainty is rarely available. The team needs to see what remains unknown and decide whether any of it blocks progress.
For a lightweight approach, start with four conditions.
The person beginning the work should understand the problem, request, or expected result.
“Update onboarding” leaves too much room for interpretation. A more workable item might say:
New account owners are missing the invitation step during onboarding. Review the current setup guide and propose an update that makes this step easier to find.
The solution remains open, but the audience, problem, and desired change are clear enough to investigate.
Avoid demanding a miniature strategy document for every task. The amount of context should match the size and risk of the work. If the item seems too large for a task, first decide whether it deserves its own project.
Several people may contribute, but one person should be responsible for moving the item forward now.
Ownership does not mean doing every part alone. The owner might gather input, arrange a review, draft the first version, or find the person who can resolve a dependency. Their job is to keep the item from sitting in an active queue while everyone assumes somebody else has it.
“Marketing owns this” is vague. “Rina will draft the launch email outline” is usable.
An unresolved question does not automatically make work unready. Record it, identify who owns it, and determine whether it blocks the immediate next action.
Suppose a launch email needs final pricing approval. The writer may still be able to prepare the structure and draft sections unrelated to pricing. Work can begin if the dependency is visible and someone is responsible for resolving it.
Useful details might include:
You do not need to solve every unknown before starting. You do need to stop pretending the unknowns are not there. If a decision matters, keep it with the brief or work item instead of leaving it buried in a chat thread. A meeting recap can help document the decision and turn it into owned work.
Ask the owner what they will do first.
They might reproduce a reported bug, draft an outline, review an existing brief, map the current handoff, or speak with the person who raised the request. The first action does not need to guarantee the final result. It should create useful progress or reduce uncertainty.
If nobody can describe a sensible first move, the item needs more context or a short conversation before entering active work.
Use this as a recommended starting point:
Add conditions only when repeated failures show that your team needs them. A team that regularly starts design work without knowing the required delivery format might add “delivery format identified.” One awkward project calls for a conversation. Five similar failures may justify a new rule.
Keep the check short and useful. A minimum viable process is usually easier to use than a long readiness checklist that nobody consults until after work has already stalled.
For routine work, the people requesting, owning, and likely to do the work should make the decision together. They need enough shared understanding to agree that the first action is responsible and that meaningful unknowns are visible.
A separate readiness approver may add an extra stop for ordinary work, so it is usually better to keep the decision with the owner and contributors. Higher-risk, regulated, or costly work may need a formal review from whoever owns an important decision or constraint. The point is to match the review to the risk, not to create a universal gate.
You can document the agreement as a short team working agreement so people know what “ready” means without relying on memory.
A vague issue says, “Mobile checkout is broken.” A ready issue could include:
The final fix remains unknown, which is normal for an issue. Investigation can still begin because the reported problem, owner, dependency, and first action are visible.
The messaging decision is visible and owned. It does not block the entire draft.
The future process has not been designed yet. Mapping the current one is still a responsible start.
These practices answer different questions:
| Practice | Question it answers |
|---|---|
| Request intake | How does a request enter consideration? |
| Definition of Ready | Can this selected item responsibly begin? |
| Acceptance criteria | How will we judge whether this particular output meets expectations? |
| Definition of Done | What shared completion standard applies to finished work? |
A request intake process collects and evaluates incoming requests. An item can pass intake and still need more context before anyone starts it.
Acceptance criteria describe what the delivered result must satisfy. They may be part of the context needed for readiness, especially when the expected output is specific, but they serve a different purpose.
Definition of Done sits at the other end of the work. It gives the team a shared standard for calling work complete.
A long Definition of Ready can turn uncertainty into delay. Mountain Goat Software’s warning about rigid readiness rules is worth considering: preconditions can become gates that obstruct useful discussion and progress.
Keep the check short enough to use in a normal conversation. Skip a separate approval chain for routine work unless the risk justifies it. Review the conditions occasionally and remove any that create paperwork without preventing a recurring problem.
Urgent incidents may begin with little more than the reported impact and a safe diagnostic step. For exploratory work, discovering the answer is part of the assignment.
Record what is unknown, who will investigate it, and what can safely happen next. Urgency may justify starting with less information. It does not make missing information disappear.
A readiness check loses much of its value when the brief lives in one tool, the open decision sits in a chat thread, and the task contains six mysterious words. The team then has to reconstruct the assignment before it can act.
Keep each task or issue beside the material needed to start it: the brief, relevant decisions, owner, open questions, and next step. This is the practical part of the readiness habit. A checklist alone cannot supply context that has been scattered across the workspace.
A simple arrangement includes:
Notework is a simpler, more opinionated workspace for small teams that want documentation and day-to-day work organized together. In Notework, a workspace contains projects, and all pages and collections belong to a project. That structure gives a team a natural place to keep the readiness agreement, supporting briefs, decision notes, and related work together rather than treating the task as an isolated ticket.
A team can use a page in the relevant project for its readiness agreement, briefs, and decision notes. Notework pages support nesting, mentions, backlinks, and comments anchored to specific blocks, so the team can discuss a particular part of a brief or decision while keeping the surrounding context nearby.
For actionable work, Notework includes Task Tracker and Issue Tracker collection presets. A collection is a structured set of full entry pages, so each task or issue can hold relevant context instead of squeezing the assignment into a title. Typed properties can make the owner, status, and date visible. Saved views can show the same entries as a table, board, list, calendar, timeline, or gallery.
This setup does not decide whether work is ready for the team. People still make that call. It simply keeps the page context, owner, unresolved decisions, and next step close enough that the call is easier to make and easier to revisit.
See also decide whether it deserves its own project.
See also document decisions and turn them into owned work.
See also keep the check short and useful.
See also a short team working agreement.