Sprint Readiness: 5 Signs Your Backlog Isn't Ready for Planning

Sprint planning is the moment teams discover whether refinement actually worked. When the backlog is ready, planning takes 30 minutes and ends with a clear commitment. When it is not, two hours later the team is still arguing about whether a story should be split, estimated, or sent back to refinement.

Below are the five signs of an unready backlog you can spot in Jira beforeplanning, with the field-level signals that expose each, and what to do about them. For the underlying checklist that defines "ready" in the first place, see our Definition of Ready template for Jira.

Sign 1: Stories without estimates dominate the top of the backlog

What it looks like

The top 20 items in the backlog have empty Story Points. The team hopes to size them "in planning", but planning is not refinement. Sizing in planning consumes the meeting, and the commitment is based on guesses that the developers later regret.

Jira signal

JQL: project = X AND sprint is EMPTY AND statusCategory != Done AND "Story Points" is EMPTY ORDER BY Rank ASC. If more than 20-30% of the top of the backlog returns from this query a day before planning, your backlog is not ready.

Fix

Make "has estimate" a criterion of your Definition of Ready and refuse to pull unestimated stories into a sprint. If the team consistently fails to estimate during refinement, the refinement meeting is too short or too unfocused — split it.

Sign 2: Acceptance criteria are missing or vague

What it looks like

The story description says "as a user I want X so that Y" and that's it. There is no AC section, or the AC is a single line like "the feature works". The developer will guess, the QA will guess, and the PO will be surprised in review.

Jira signal

Hard to detect with pure JQL because acceptance criteria usually live inside the description text. Two practical approximations: stories whose description is under 200 characters (use a custom field validation rule), or stories without a dedicated AC custom field filled in. Either signals an under-specified story.

Fix

Move AC into a dedicated custom field. This makes it queryable and makes its absence visible on the issue. Add the field as a required column on the refinement view. A 200-character minimum description check is a crude but effective floor.

Sign 3: Subtasks created but no assignee, ever

What it looks like

The story has eight subtasks for "backend", "frontend", "QA", "docs". All are unassigned. The implicit plan is to figure out who does what in planning — which is just another way of saying the team has not actually broken the work down.

Jira signal

JQL: parent in (top-10-backlog) AND assignee is EMPTY. If most subtasks of refined stories have no assignee, the team is treating subtask creation as a checklist exercise rather than work assignment.

Fix

Either assign at refinement (preferred) or delete the placeholder subtasks. Empty subtask shells are worse than no subtasks: they create false confidence that breakdown happened.

Sign 4: Stories carry "blocked by" links to incomplete issues

What it looks like

A story near the top of the backlog has a "blocked by" link to another story that is still in "In Progress". The team plans to pull both into the next sprint and sort out the order at standup. This works exactly until the blocker slips, at which point the blocked work also slips, and the sprint goal is at risk.

Jira signal

JQL: issueLinkType = "is blocked by" AND linkedIssue in (status != Done). Any top-of-backlog story matching this is at risk.

Fix

Resolve the blocker before pulling the blocked story in, or rank the blocker much higher so it is done early in the sprint. Better: make "no open blocking dependencies" a DoR criterion so the backlog reflects only stories the team can actually start.

Sign 5: The PO has not touched the top of the backlog in two weeks

What it looks like

The team refines stories during refinement meetings but the PO has not updated rank, AC, or priority on the top of the backlog for two weeks. The implication is that the priorities the team will plan against may not reflect current business reality. Planning commitments made against stale priorities are how sprints end up delivering things nobody actually wanted this month.

Jira signal

JQL: project = X AND sprint is EMPTY AND statusCategory != Done AND updated < -14d ORDER BY Rank ASC. If the top 10 items all match, the backlog is on auto-pilot.

Fix

A PO-led pre-planning review the day before. 30 minutes, top 15 items, confirm rank and AC. Touch each story so the "updated" field reflects the deliberate pass.

Catching all five before planning

Each sign above is one JQL query, but running five queries a day before planning is friction. Most teams stop doing it after a few sprints. The alternative is a continuous readiness score per issue — a 0-100% number that reflects all the DoR criteria the team cares about, updated as fields change. ReDoworks this way: every issue has a score visible in the issue panel and on a project-level dashboard, so "is the backlog ready?" has a glance-level answer.

Whatever tool or process you use, the principle stays: the cheapest place to fix an unready story is in refinement, not in planning, and not mid-sprint. The signals are already in Jira — the question is whether you look at them in time.

Key takeaway

A backlog that is not ready for planning shows itself in five consistent signals: missing estimates, vague AC, unassigned subtasks, unresolved blockers, and a stale PO touch. All five are detectable in Jira before the meeting starts. The teams that plan cleanly are not lucky — they have made the signals visible and made ignoring them costly. For the broader playbook on making DoR stick without slowing the team, see how to enforce Definition of Ready in Scrum without slowing down.