Guide
A backlog is a decision queue, not a wish list.
Every item in a backlog is a claim on the team's next weeks, and the backlog's one job is to keep those claims ordered, honest and small in number. This guide covers how to run one people actually trust: refinement that works, prioritisation methods with their failure modes stated plainly, a Definition of Ready you can copy, and a Jira structure that does not fight you.
Written by Israel Bankole, founder of Backlog.cloud. Last updated 9 August 2026.
In this guide
The shape of health
What a healthy backlog looks like
The Scrum Guide defines the product backlog as an emergent, ordered list of what is needed to improve the product, and the single source of work the team undertakes. Three words in that definition do all the lifting. Emergent: it changes as you learn, so anything carved in stone does not belong in it. Ordered: a strict sequence, not priority buckets, because two items cannot both be next. Single source: if work reaches the team through side doors, the backlog is fiction.
A healthy backlog has a distinctive shape. The next sprint or two of work is small, estimated and ready. The middle distance is coarser: real items, a paragraph each, no acceptance criteria yet. The far end is a handful of large, vague statements of intent. Detail falls away with distance on purpose, because detail added early rots before it is built. Anyone who opens the backlog can answer "what are we doing next and why?" in under a minute.
The unhealthy version is so common it deserves its own name: the 400-item graveyard. It grows one reasonable-sounding ticket at a time, because adding is free and deleting feels rude. You know you are standing in one when:
Items older than the product strategy
Tickets from three roadmap pivots ago, kept "in case". Nobody will ever build them, but deleting feels like admitting the time was wasted. It was. Delete them anyway.
Nobody can say what item 50 is without opening it
A backlog the product owner cannot narrate from memory past the first two sprints is not a plan, it is a filing cabinet. Depth of detail should fall away with distance.
Duplicates with different words
The same request captured four times from four meetings because nobody checked before adding. Every duplicate splits the evidence for how much the thing is wanted.
Priority means "order we thought of them"
If the top of the backlog is chronological, nobody is making decisions. The queue order should change when the world changes, and it should be defensible out loud.
Adding is free, removing needs a meeting
The asymmetry that builds graveyards. Make adding cost one honest sentence about value, and make removing cost nothing.
The fix is not a heroic weekend cleanup, which just resets the clock on the same decay. It is changing the asymmetry: every item entering the queue costs one honest sentence about who wants it and what it is worth, and any item can leave without a eulogy. A deleted item that mattered will come back. That is the test.
Refinement
Backlog refinement, and the word grooming
Refinement is the working session where raw backlog items become buildable ones: splitting oversized stories, writing acceptance criteria, estimating, arguing about order, and deleting what no longer earns its place. Atlassian's guide to refinement meetings frames it as keeping the backlog up to date and ready for upcoming sprints, which is right, but undersells the deletion part. A refinement session that only adds detail is half a session.
On the name: this activity was widely called backlog grooming for years, and early editions of the Scrum Guide used that word. The 2013 update renamed it refinement, partly because of the connotations the word grooming had taken on, and refinement has been the standard term since. Worth knowing both, because half the material you will find still says grooming, but use refinement.
The Scrum Guide is deliberately loose here: refinement is described as an ongoing activity, not a prescribed event with a prescribed length. That looseness is licence to fit it to your team, not licence to skip it. Teams that drop refinement do not save the time, they move it into sprint planning, where it happens worse, under pressure, with the whole team watching two people negotiate acceptance criteria.
A concrete definition of a good session: the team leaves with two sprints of ready work, at least one oversized item split, at least one item deleted or demoted, and the decisions recorded somewhere better than one person's notebook. What that looks like meeting by meeting is covered on the backlog refinement meeting page.
Logistics
Cadence, length and who should be in the room
The cadence that works for most teams: one session per week, 45 to 60 minutes, refining roughly one sprint of work per sprint consumed. Weekly beats fortnightly because the queue of unrefined items stays short enough to finish, and short sessions beat marathons because refinement quality collapses after the first hour.
Both extremes fail in predictable ways. Refine only the day before planning and every unknown discovered becomes a planning crisis with no time to run a spike. Refine a quarter ahead and you polish detail that will be wrong by the time it is built, which is wasted work and, worse, creates attachment to stale plans.
| Who | What they are there for |
|---|---|
| Product owner or PM | Brings the why: candidate items, the value argument, the customer evidence. Makes the final ordering call. |
| Two or three engineers | Bring the how much: feasibility, hidden complexity, dependency warnings. Rotate attendance so knowledge spreads and nobody loses a full afternoon weekly. |
| A tester or QA-minded engineer | Asks the question that splits stories: "how would I check this?" Catches untestable acceptance criteria before a sprint does. |
| Designer, when flow changes are on the table | Stops the team refining a story whose design does not exist yet, which is the most common reason ready items turn out not to be. |
| Not the whole department | Refinement with twelve people is a presentation. Keep it small enough that everyone present is expected to talk. |
Ordering the queue
Prioritisation methods, compared honestly
Every prioritisation framework is a machine for turning arguments into an ordering. None of them removes the judgement, they just structure the argument, and each one has a characteristic way of going wrong that its advocates rarely mention. Here are the four you will actually encounter, with the failure modes stated plainly.
| Method | How it works | Where it shines | Where it breaks |
|---|---|---|---|
| Value vs effort | Score each item on expected value and expected effort, take the best ratio first. | Fast, intuitive, and good enough for most teams most of the time. Forces the value question to be asked at all. | Both numbers are guesses, and value guesses are usually optimistic in whatever direction the loudest person prefers. Works only if scores get challenged. |
| WSJF | Weighted Shortest Job First, from SAFe: divide cost of delay by job duration, do the highest ratio first. | Surfaces small urgent items that flat value scoring buries. The cost-of-delay conversation is genuinely clarifying. | The arithmetic gives false precision to made-up inputs. Summing three estimated components and dividing by a fourth produces a number that looks objective and is not. |
| Cost of delay | Ask what it costs per week to not have each item: lost revenue, risk exposure, dependency blockage. | The right mental model even when unquantified. "This costs us nothing to delay" kills zombie items faster than any scoring session. | Genuinely hard to put numbers on for most product work. Teams either give up or invent figures, and invented figures are worse than ranked intuition. |
| MoSCoW | Sort items into Must have, Should have, Could have and Will not have. | Good for scoping a fixed deadline or a contract conversation, because Will not have is an explicit, recorded decision. | Gravity pulls everything into Must. When 70 percent of a release is Must have, the method has stopped prioritising, and a category is not an order: ten Musts still need ranking against each other. |
The honest summary: for a single team, ranked value vs effort with challenged scores covers 90 percent of situations. Reach for WSJF when small urgent items keep losing to big shiny ones, because that is the specific distortion it corrects. Use MoSCoW for deadline scoping conversations with stakeholders, never as the day-to-day ordering, because a category is not a queue. And keep cost of delay as the question you ask even when you never write the number down.
Whatever the method, the output must be a strict order. The framework is how you argue. The ordered list is what you decide. A backlog sorted into "High, High, High, Medium" has used a framework and made no decision at all.
Quality bar
Definition of Ready, with a checklist you can copy
A Definition of Ready is the team's shared answer to one question: what must be true about an item before we commit a sprint to it? Worth saying clearly, because it gets asserted otherwise in job interviews daily: DoR is not part of Scrum. The Scrum Guide defines a Definition of Done and no Definition of Ready. It is a community practice, and a good one, provided it stays a conversation trigger rather than a gate.
The distinction matters. Used well, the checklist below is what a team glances at in refinement to notice "we never talked about how to test this". Used badly, it becomes a stage gate where work queues for sign-off, which quietly rebuilds the requirements-handover process that iterative delivery was meant to replace. If an urgent production issue can never enter a sprint because it lacks a persona clause, the DoR is running the team instead of serving it.
Definition of Ready. An item enters a sprint when: [ ] The value is stated: who wants this and what changes for them [ ] Acceptance criteria exist, numbered, testable, unhappy paths included [ ] The team has discussed it and had questions answered [ ] It is estimated, and small enough to finish well inside one sprint [ ] Dependencies are known: none open, or explicitly accepted [ ] Design exists for any user-facing change, or is agreed unnecessary [ ] We know how we will demo it at sprint review
Seven checks is the ceiling worth having. Teams that grow their DoR to fifteen items stop reading it. Adapt the wording, argue about which checks earn their place, and revisit it when the team changes, because a quality bar nobody remembers agreeing to is just bureaucracy with a Scrum accent. The counterpart at the other end of the sprint, the Definition of Done, is defined in the Scrum Guide and deserves the same treatment: short, agreed, actually used.
Tooling
Structuring the backlog in Jira
Jira gives you four grouping constructs, and most backlog misery traces back to using them for jobs they were not built for. The safe mental model: epics group work by goal, versions group it by release, components group it by area of the system, labels catch everything cross-cutting. One ordered backlog underneath all of it, because the rank field, not any grouping, is the actual decision.
| Construct | Built for | Common misuse |
|---|---|---|
| Epics | Group stories under a goal that spans sprints: "self-serve exports", "checkout rework". An epic should be closable, which means it needs a definition of done, not just a theme. | Permanent buckets like "Frontend" or "Tech debt" that never close. That is a component wearing an epic costume, and it makes epic-level progress reporting meaningless. |
| Fix versions | Group items by release: "2026.09", "Mobile 3.2". The release burndown and release notes both hang off this field. | Versions as a wish list, where "Future" holds 200 items. A version with no plausible date is just the graveyard with a label. |
| Components | Stable areas of the system: billing, search, notifications. Good for routing, ownership and spotting which area generates the most bugs. | Components as priority signals or team names that change every reorg. Keep them mapped to the architecture, which changes slower than the org chart. |
| Labels | Cheap, flexible tags for cross-cutting concerns: "compliance", "customer-commitment", "needs-design". Useful precisely because they are informal. | Thirty ad hoc labels nobody agreed, half of them synonyms. Prune quarterly or stop trusting label-based filters. |
Two structural rules save the most pain. Keep one backlog per product, not per team function, because the moment "the frontend backlog" exists, prioritisation across the product stops. And write descriptions knowing Jira renders Atlassian Document Format, not Markdown, which matters as soon as anything generates or imports tickets. The mechanics of getting well-formed items into Jira from a conversation are covered on meeting notes to Jira.
Worked example
The top of a healthy backlog, annotated
A snapshot of the first seven items of a backlog doing its job. Notice the gradient: items 1 to 4 are ready, item 5 is refined but waiting on a spike answer, item 6 is deliberately coarse, and the epic sits alongside as a container rather than clogging the queue. Notice too that a bug and a spike compete in the same queue as stories, which is the point.
| # | Type | Item | State | Why it sits here |
|---|---|---|---|---|
| 1 | Story | Reuse last delivery address at checkout | Ready: refined, criteria agreed, estimated | Top support complaint this quarter. Sized at 3 points in last refinement. |
| 2 | Bug | VAT recalculated wrongly on mid-cycle upgrades | Ready: reproduction confirmed | Finance needs it before quarter close. Cost of delay is real and weekly. |
| 3 | Story | Export audit log as CSV, last 30 days | Ready: first slice of the compliance epic | Thinnest vertical slice. Date ranges and scheduling deliberately excluded. |
| 4 | Spike | Can the audit table serve a year of data without timeouts? | Ready: timeboxed to two days | Answers the unknown blocking estimation of the full export story. |
| 5 | Story | Date range picker on audit export | Refined, not estimated | Waits on the spike. Will be estimated next session. |
| 6 | Story | Saved card management in account settings | Coarse: one paragraph, no criteria | Two sprints out at best. Deliberately not detailed yet. |
| 7 | Epic | Self-serve compliance exports | Container: three of five stories drafted | Progress visible at a glance. Closes when the API surface ships. |
How each of these item types should be written, split and given acceptance criteria is the subject of the companion user stories guide.
In practice
Keeping the backlog connected to the meetings that feed it
A backlog decays for one structural reason: the decisions that should shape it happen in meetings, and meetings evaporate. Refinement agrees a split and new criteria, planning surfaces a dependency, a stakeholder call reorders the quarter, and each time somebody is supposed to transcribe the outcome into the tracker afterwards. Some of it makes the journey. The rest becomes the gap between what the team agreed and what the backlog says, and that gap is where trust in the backlog dies.
The manual fix is discipline: end every session by updating the backlog together, on screen, before anyone leaves. It works, and it costs ten minutes of the meeting every time, which is why it erodes under pressure.
The tooling fix is to stop relying on the transcription step at all. Backlog.cloud sits in refinement and sprint planning calls, or reads the transcript afterwards, and drafts the items the conversation actually produced: stories with numbered criteria, bugs with reproduction context, spikes with their timebox, each anchored to the verbatim quote it came from. A human reviews the drafts, discards what does not belong, and pushes the rest to the backlog. The AI backlog generator page shows the full output shape. The ordering, the deleting and the saying no stay exactly where this guide puts them: with a person.
FAQ
Product backlogs, answered
- How many items should a product backlog have?
- Small enough that the product owner could narrate it from memory: for most teams that is a few dozen items, not several hundred. A useful shape is two sprints of ready work, a coarse middle the team refines as it approaches, and nothing older than the current strategy. Past that, items are noise that makes every ordering decision slower.
- Is backlog grooming the same as backlog refinement?
- Same activity, older name. Early editions of the Scrum Guide called it grooming and the 2013 update renamed it refinement, partly because of the unfortunate connotations the word grooming carries. Refinement is the current term and the one worth using, but search results and older books still say grooming.
- How often should backlog refinement happen?
- A weekly session of 45 to 60 minutes suits most teams, roughly keeping pace with one sprint of consumption. The Scrum Guide treats refinement as an ongoing activity rather than a prescribed event, so the cadence is yours to set. The failure modes sit at the extremes: refining once per sprint the day before planning, or refining so far ahead that detail rots before it is built.
- Who owns the product backlog?
- The Scrum Guide makes the product owner accountable for the backlog: its content, its ordering and making it understood. Accountable does not mean sole author. Engineers, testers and stakeholders all feed it, and refinement is a team conversation. What the product owner cannot delegate is the ordering decision and the authority to say no.
- Is the Definition of Ready part of Scrum?
- No. The Scrum Guide defines a Definition of Done but not a Definition of Ready. DoR is a community practice that many teams find useful as a shared quality bar for what enters a sprint. Treat it as a checklist that starts conversations, not a stage gate that blocks work, because a rigid DoR quietly reinvents the handover it was meant to prevent.
- Should bugs go in the product backlog?
- Yes, one queue. The moment bugs live in a separate list, one of the two lists is being ignored, and prioritisation stops being honest because a bug fix and a feature are never weighed against each other. A production bug competing for the top slot against a new story is exactly the decision a backlog exists to force.
- Can AI maintain a product backlog from meetings?
- It can draft the inputs. An extraction engine listening to refinement and planning calls can produce stories, bugs and spikes with acceptance criteria, each anchored to the quote it came from, and land them in a review queue. Ordering the backlog and saying no remain human decisions, and the review step exists precisely so nothing enters the queue unexamined.
Keep going
Related workflows and resources
User stories guide
Format, INVEST, splitting and acceptance criteria, in full depth.
Backlog refinement meetings
What a refinement session should produce, and how to capture it.
Sprint planning meetings
Turning the planning conversation into sprint-ready items.
Meeting notes to Jira
The full path from a conversation to a well-formed Jira issue.
AI backlog generator
Draft stories, bugs and spikes from meetings, with evidence quotes.
For product owners
How product owners use Backlog.cloud across the sprint cycle.
Let the backlog keep up with the conversations that shape it
Backlog.cloud turns refinement and planning calls into review-ready backlog items, each anchored to the quote it came from. You order the queue, it does the transcription. 3 free generations, no card.