Why Is a Ticket Marked Ready Still Blocking the Team?

Challenge: Can we prove that every ticket our team calls Ready can be started right now, without another round of questions?

When that proof is missing, each failed pickup costs the team directly. Staff spend hours clarifying a request that should have been complete. AI workers burn tokens and compute on work they cannot finish. Every ticket behind the stalled one waits longer in the queue. A ticket is Ready only when a worker can read the complete authoritative request, verify its outcome and runnable acceptance criteria, confirm its routing and executable type, and find any shared-contract evidence its scope requires; the label records that decision and cannot replace the evidence.

Picture a familiar scenario. A queue holds ten tickets labeled Ready. A person or an AI worker picks the first three and stalls immediately. One has no acceptance criteria. Another has no recorded decision showing which team and queue own it. The third depends on a plan that was never decided. All three pickups consumed attention, tokens, and time before anyone discovered the tickets were incomplete. This scenario is illustrative -- plug in your own numbers to see the real cost.

Active rework cost per failed pickup = clarification people-hours x loaded hourly rate + AI input and output tokens x provider token rate + compute or wall-clock units x billed rate.

Report elapsed queue delay separately in hours or days so it is not priced twice. No published source measured these variables for any specific queue. Substitute your team's observations and the cost becomes concrete.

Many Scrum and Agile teams use a Definition of Ready to decide whether work is clear, feasible, and testable before they commit. We apply a more specific version: a six-layer, read-only check that returns exactly what is missing and refuses to guess.

A ticket is Ready only when a worker can read the complete authoritative request, verify its outcome and runnable acceptance criteria, confirm its routing and executable type, and find any shared-contract evidence its scope requires. The label records that decision. It cannot replace the evidence.

Just In Time AI can help you turn work intake into a reliable AI operating system with clear evidence, routing, and stop conditions, then prove the smallest useful improvement before expanding. Explore AI Systems Setup and Coaching.

What: What should Ready mean to the person picking up the work?

Ready should mean one thing: a qualified worker can begin now. The ticket contains enough evidence that the first action is execution, not reconstruction.

Use six layers to enforce that meaning. Each layer targets a distinct failure mode. All six must pass before a ticket enters the pickup queue. When any layer fails, the check names every gap so grooming can repair the actual record.

Here is how the readiness decision works:

This public-safe decision table demonstrates the three possible outcomes without exposing private service routes, credentials, or organization-specific formats.

The six layers, in order:

1. Server transition floor: At the Ready transition, require title, work type, destination lane, repository identity, outcome description, acceptance criteria, and, only for a parent item, a decided-plan reference or recorded reason one is unnecessary. This minimum readability floor is not the owner, dependency, routing, or executable-type decision.
2. Verifiable acceptance criteria: Require six testable parts that define the outcome.
3. Executable type and routing: Require a directly executable work type -- a Task or Bug that needs no further planning -- plus a routing result that records which team and queue own it. Require an estimate showing the work is small enough for one pickup.
4. Conditional shared-contract evidence: Require reviewed evidence when the work changes a shared interface.
5. Complete authoritative detail: Read the full ticket record and stop if it is unavailable.
6. Read-only audit: Report every gap and make zero changes.

Why is the server check only the first readiness layer?

The server-side floor enforces minimum fields when a ticket transitions to Ready. It requires a title, work type, destination, repository identity, outcome description, and acceptance criteria. A parent ticket also needs a reference to a decided plan or a recorded reason that none is needed.

This floor exists because tickets used to arrive in the Ready queue with no description, no destination, or no acceptance criteria. The server now rejects the transition when a required field is blank. That stops the most obviously incomplete tickets from reaching the queue.

The floor is necessary. It is not sufficient. A ticket can pass every minimum field check and still lack a runnable verification method, a routing result, or reviewed evidence for a shared-contract change. Checking for the presence of fields is a readability test. Readiness requires the five layers that follow.

What must acceptance criteria prove before work begins?

Acceptance criteria define what done looks like in testable terms. Non-empty prose alone does not pass. We require six parts:

1. Baseline: The current measurable state before the work begins.
2. Target: The specific measurable state the work must reach.
3. Runnable method: A verification procedure a person or script can execute to confirm the target was met.
4. Failure conditions: Explicit conditions under which the acceptance criteria are not met, including false-positive scenarios.
5. Context validity: The environment, configuration, or preconditions under which the method produces a trustworthy result.
6. Before-and-after sweep: Comparable observations taken before and after the work so the change is provable rather than asserted.

When any of the six parts is missing, the ticket fails the readiness check at this layer. The gap report names which parts are absent so the ticket owner can add the evidence.

Presence is the floor, not the bar. A reviewer must confirm that the baseline came from the named method and the target is achievable. Someone who did not implement the work must be able to run the verification, and that verification must expose a false pass. The reviewer must also confirm that the context is the real one. A ticket whose six labels contain placeholders still fails.

This layer prevents a common failure. A ticket describes an outcome in narrative form but provides no method to verify it. A worker picks it up, builds to their interpretation, and discovers at review that the intended outcome was different. That rework belongs in grooming, not execution.

How do routing and executable type prevent false starts?

Two conditions must both be true before a ticket is eligible for pickup.

Routing result: The ticket must carry a successful result from the authoritative router. The router determines where the work belongs: which team, which system, which queue. When the routing result is absent or unresolved, the worker who picks up the ticket may discover mid-execution that the work belongs somewhere else. That is a wasted pickup.

Executable type: The ticket must be a bounded, directly executable work item that is small enough to finish in one pickup. Record an estimate and the basis for it, and split anything larger before Ready. Planning containers such as epics, features, and user stories organize work but cannot be performed directly. When a planning container lands in the pickup queue, the worker has to decompose it into executable tickets before useful work starts. Decomposition is planning, not execution, and it belongs before the ticket reaches Ready.

Either condition independently blocks pickup. A ticket with a valid routing result but a non-executable type is not ready. A ticket with an executable type but no routing result is not ready. The same is true when a dependency, blocker, plan, or decision the work relies on remains unresolved: link it, name the owner who can resolve it, and keep the ticket out of Ready until the dependency clears.

When does a ticket need shared-contract evidence?

Not every ticket touches a shared interface. The readiness check distinguishes two cases.

The work changes a shared contract: When a ticket proposes changes to a database schema, an API, an identity boundary, or another interface shared across multiple components, reviewed evidence of that shared-contract decision is required before pickup. Without it, the worker risks building against a contract that the other consumers never agreed to. The cost of reversing a broken shared contract cascades across every consumer of that interface.

The work does not change a shared contract: When the ticket's scope falls within one component and touches no shared interface, the readiness check records that the condition does not apply. A truthful "not touched" decision is valid and is not a gap.

This layer is conditional. It fires only when the scope requires it. The point is to catch shared-contract changes at intake, where the cost of correction is lowest, rather than at integration or deployment where reversals cascade.

Why must the audit read the full ticket and remain read-only?

Two principles govern the final layers of the check.

Complete authoritative detail: A summary list, a title, or a truncated view can omit the description, the acceptance criteria, the required reading, or the evidence. If the complete ticket record cannot be read, is partially loaded, or cannot be reconciled, the check stops with COULD_NOT_RUN. That result means the check could not observe the ticket. It does not mean the ticket passed or failed. Guessing from a partial view is how incomplete tickets appear to pass.

Read-only audit: The readiness check reports every failure reason and records zero mutations. It does not claim, edit, move, close, or approve the ticket. Repair and promotion remain separate actions with their own authorization. A check that modifies the ticket it evaluates can mask its own findings or introduce changes no one reviewed. Keeping the audit read-only means the report is a clean diagnostic that grooming can trust.

Re-run the check at the moment of pickup, not only when the ticket first enters Ready. A prior PASS expires when anything it depended on changes, including a dependency, shared contract, routing rule, acceptance method, or whether the work is still needed.

Here is the readiness check as a re-runnable framework:

1. Check the exact server transition floor, then groom dependencies: Confirm title, work type, destination lane, repository identity, outcome description, acceptance criteria, and any parent-plan requirement before allowing the Ready transition. Separately link every dependency, blocker, plan, or decision the work relies on, name the owner who can resolve it, and keep it out of pickup until it clears.
2. Verify acceptance criteria are credible and independently runnable: Require a baseline, target, verification method, failure conditions, context validity, and comparable before-and-after observations. Confirm the baseline is measured, the target is achievable, and someone other than the implementer can run a method that would expose a false pass. Non-empty prose and filled labels are not enough.
3. Confirm routing, executable type, and size: Require a successful routing result, a directly executable work type, and an estimate with its basis showing the work can finish in one pickup. Planning containers, oversized work, and unrouted tickets stay in grooming.
4. Check conditional shared-contract evidence: When the ticket changes a shared interface, require reviewed evidence. When it does not, record that the condition does not apply.
5. Read the complete authoritative record: If the full ticket detail is unavailable or cannot be reconciled, stop with COULD_NOT_RUN. Do not guess from a summary.
6. Keep the audit read-only and current: Report every gap and make zero changes. Repair and promotion are separate actions. Re-run the audit at pickup and after any material dependency or evidence changes.

Introduce the gate in two stages. First, run it as a report over today's Ready queue, count failed pickups for a baseline, and groom every failure into a visible repair queue. Give each held ticket a named owner and a review date. Silence keeps the ticket out of Ready and triggers escalation on that date; without a date, silence becomes an indefinite stall. Enforce the gate only after the repair queue is clean.

After enforcement, re-count failed pickups and clarification cycles to test whether the control improved the outcome. Track how many tickets remain in the repair queue and how long they wait there as a separate stranding measure; a lower pickup-failure count alone can hide work that never reaches Ready.

Why: Why does readiness evidence matter to the business?

A failed pickup moves cost into execution instead of removing it during grooming. Staff lose the time they expected to spend delivering. AI workers consume tokens and compute while reconstructing requirements. Work behind the stalled ticket waits longer, and the queue becomes harder to trust.

The damage compounds when the rule is unreliable. Repeated stalls frustrate the team. A worker who guesses can carry an unresolved requirement into a customer-facing change. When tickets repeatedly pass a control without being ready, people learn that the control is ceremonial and compliance decays with it.

The six-layer decision makes those costs visible before commitment and again at pickup. It gives the accountable operator a defensible reason to hold work, identifies the owner and repair needed, and preserves a clean record of what the check could actually observe. The public validation-gates pattern illustrates the broader principle that durable work can require multiple blocking review layers with explicit rejection criteria. It does not implement this ticket-readiness method.

Artifacts

• JitNeuro validation-gates pattern: a public example of multiple blocking review layers with explicit rejection criteria. It does not implement or independently verify this six-layer ticket-readiness method.

Bottom Line: What should stay out of the Ready queue?

For the practical method, read the published companion, How do I verify a ticket is actually ready before a team picks it up?. It teaches the same six-layer, read-only review, its PASS/FAIL/COULD_NOT_RUN outcomes, and the required recheck at pickup. This reciprocal link connects the published pair.

Keep any ticket that cannot satisfy every applicable readiness layer out of the pickup queue. That decision protects staff and AI time for work the business has actually specified and gives the accountable operator a defensible reason to hold incomplete work.

The value compounds each time the check prevents another failed pickup. It reduces team frustration from reopening the same questions, lowers the risk that an unresolved requirement reaches a customer, and protects compliance credibility by making Ready a dependable control. Each recurrence avoided also saves another round of staff hours, AI calls, token and compute charges, and queue delay spent re-deriving an answer the business should have settled before execution.

Frequently Asked Questions

How do I check whether a ticket is ready before assigning it?

Read the complete ticket and verify that its business outcome, authoritative context, dependencies, owner, routing, and testable acceptance criteria are present and mutually consistent. Keep the ticket out of the pickup queue when any required layer is missing. A Ready label is the result of that check, not evidence by itself.

What information should I add before marking a work item Ready?

Add the intended business result, the current baseline, the target, the owner, dependencies, valid source context, and a runnable verification method with explicit failure conditions. Include comparable before-and-after observations so the worker can prove the outcome instead of treating non-empty prose as readiness.

What should I do if I cannot read the complete ticket before work starts?

Stop with COULD_NOT_RUN. Do not infer readiness or failure from a title, a summary row, a truncated response, or an inaccessible record. Restore and reconcile the complete authoritative detail first, then rerun the read-only readiness review before anyone claims the work.

What should I do when a Ready ticket is missing requirements or acceptance criteria?

Stop the pickup, record the missing requirement or untestable condition, and return the ticket to refinement with a named owner for the decision. Do not let the worker guess from the title or fill in scope silently. Rerun the readiness check after the authoritative ticket is repaired.

Should a readiness review change or claim the ticket?

No. Run the readiness review as a read-only decision and report every missing or conflicting layer without editing the evidence being judged. Route repairs, promotion, approval, claim, and execution through their separately authorized actions, then review the repaired ticket again.

Join for free for practical AI operating lessons you can use with your team.

Want to work together or talk directly? Contact me: https://danstolts.com/