Blog ·
Groomed backlog: what it looks like in Jira, and how to keep one
A groomed backlog is a backlog where the items at the top are ready to be pulled into the next sprint: ranked in the order the team should do them, small enough to finish inside one sprint, estimated, and written clearly enough that nobody has to ask what "fix the thing" meant. The items further down can stay rough. In Jira, that means the top of the Backlog view reads like a plan, while the bottom is allowed to read like a notebook. The hard part is keeping it that way, because grooming is a habit, and habits are the first thing a busy sprint drops.
This guide covers what "groomed" means in practice, how to get a Jira backlog there in one session, and how to make that session come back every sprint on its own.
A note on words. Many teams now say backlog refinement instead of grooming, and the Scrum Guide uses "refinement". They mean the same activity. Jira Cloud has also been renaming things: projects are spaces and issues are work items in much of the interface. This article uses both sets of words.
What a groomed backlog actually looks like #
A groomed backlog is a matter of the top of the list, rather than the whole list. A useful test is to look at roughly the next one and a half sprints of work and ask five questions of every item in it.
| Check | Groomed | Not groomed yet |
|---|---|---|
| Rank | In the order the team should do it | Newest first, or whatever order it was created in |
| Size | Fits inside one sprint | "Rebuild billing" as a single story |
| Estimate | Has story points or a time estimate | Blank |
| Description | Says what done looks like | A title and nothing else |
| Owner of the question | Open questions have a name next to them | Nobody knows who will answer |
If the top of the backlog passes those five checks, sprint planning becomes a short meeting. If it does not, planning turns into refinement, and the sprint starts late. The planning half of that story is in Jira for sprint planning.
Everything below that top slice can be loose. An idea captured as one line is fine at rank 80. Grooming it now would be wasted effort, because by the time it reaches the top the details will have changed.
How to groom a backlog in Jira, step by step #
Set aside an hour with the product owner and at least two people who will do the work. Open the space, then the Backlog tab.
- Clear out what is dead. Scroll to the bottom first. Anything that has sat untouched for months, duplicates another item, or describes a problem that no longer exists gets closed with a resolution that says why. A shorter backlog is easier to rank.
- Rank the top. Drag the items the product owner most wants done to the top. Rank is the single most useful signal in planning, because the team pulls from the top down.
- Split anything too big. A story that would take more than a sprint becomes two or three stories, each one delivering something that can be shown. Use subtasks for the steps inside a story, and separate stories for pieces that could ship on their own.
- Write the acceptance criteria. For each item near the top, add a short list in the description: what the reviewer checks to call it done. Two to five bullet points is plenty.
- Estimate. Use whatever unit your board is set to: story points, time, or item count. Estimate enough items to cover about one and a half sprints.
- Name the open questions. Anything the team cannot estimate gets a comment with the question and the person who will answer it, or a spike to find out.
Two Jira features make this faster. A quick filter on the board, for example "Story Points" is EMPTY, shows exactly which of the top items still lack an estimate. And the epic panel on the left of the backlog lets you groom one epic at a time instead of scrolling the whole list.
A JQL filter for "needs grooming" #
Save a filter the team can open at the start of every session:
project = ABC AND statusCategory = "To Do" AND sprint is EMPTY
AND ("Story Points" is EMPTY OR description is EMPTY)
ORDER BY Rank ASC
Replace ABC with your space key, and the story point field with your estimation field if you use a different one. The result is the list of backlog items that are not ready yet, in rank order, so the session starts at the top of that list and works down.
Who grooms, and how often #
Grooming is a team activity, led by the product owner. The product owner brings the order and the reasons; the people doing the work bring the size and the questions. A backlog groomed by the product owner alone tends to have confident estimates that nobody on the team agreed to.
Frequency is where most teams go wrong. Common patterns:
| Pattern | Works for | Risk |
|---|---|---|
| One session per sprint, mid-sprint | Two-week sprints, stable teams | Skipped when the sprint is busy |
| Two short sessions per sprint | Fast-moving backlogs | More meetings on the calendar |
| Continuous, no fixed session | Small teams with one owner | Quietly stops happening |
| Only right before planning | Nothing, in practice | Planning becomes refinement |
Mid-sprint is the usual sweet spot. Far enough from the last planning that new work has arrived, far enough from the next one that questions can be answered before it.
Whichever rhythm you pick, the failure mode is the same. The session lives in somebody's head or in a calendar invite, the sprint gets busy, it is skipped once, then twice, and by the third planning meeting the top of the backlog is raw again.
Keeping it groomed: make the session a ticket #
A calendar invite reminds people a meeting exists. It does not put the work on the board, give it an owner, or show up in the sprint as something the team committed to. The sessions that keep happening are the ones that exist as a work item in the sprint, with an assignee and a checklist, because then skipping it is visible.
The grooming ticket itself is small. A summary like "Backlog refinement, sprint 42", the product owner as assignee, a due date in the middle of the sprint, and a checklist as subtasks:
- Close dead and duplicate items
- Rank the top two sprints of work
- Split anything bigger than a sprint
- Acceptance criteria on the top items
- Estimate the top items
- Answer or assign the open questions
The question is how that ticket gets created every sprint.
Three ways to create the grooming ticket every sprint #
| Approach | Setup | Survives the organiser going on leave | Subtasks included | Cost |
|---|---|---|---|---|
| Someone creates it by hand | None | No | If they remember | Staff time |
| Jira Automation scheduled rule | One rule with a trigger and a create action | Yes | With extra actions | Included with Jira as of September 2026, counts against the site's automation allowance |
| A scheduling app such as Recurring Work Items | One rule | Yes | Built into the rule | Free up to 10 users |
By hand is fine for a team with a scrum master who owns the ritual and never takes a holiday. Add "create the refinement ticket" to the planning checklist.
Jira Automation can do it with a Scheduled trigger and a create action, then more actions for each subtask. It suits a site that already runs a lot of Automation and has room under its limits; the details are in Jira Automation pricing and Jira Cloud automation limits. A fortnightly mid-sprint schedule usually means a cron expression, which has its own traps.
A scheduling app holds the schedule and the ticket together. In Recurring Work Items for Jira, a project admin writes the rule once: the item type, summary, description, assignee, due date, labels and an ordered list of subtasks, which for refinement is the checklist above. The item appears in that space on the day it is due. Titles and dates can carry tokens, so the ticket reads "Backlog refinement, week of 5 Oct" instead of a copy of last time's title. Before saving, the rule shows its next runs, so you can see that "every second Wednesday" lands where you meant, and working-day handling decides what happens when a date falls on a holiday.
Every item a rule creates carries the label recurring-<rule id>, so a JQL search lists every refinement session that rule ever produced, done or not. That is a quick way to see whether the ritual is actually happening. The app is scoped to the space you enable it in, so one team's rules never land on another team's board. It is free for up to 10 users, and from $82.50 a year for 11 to 15 users.
Other recurring work that keeps a backlog healthy #
Refinement is the obvious one. A few more jobs come back on a rhythm and do the same work of keeping the backlog honest:
- A monthly backlog cleanup, separate from refinement, for the bottom of the list: close anything older than a set age that nobody has ranked up.
- A quarterly review of epics, to close finished ones and re-rank the rest against the current roadmap.
- The sprint retrospective, whose action items often become backlog items. Jira retrospective template covers that ticket.
- Routine maintenance such as dependency updates, which otherwise arrive mid-sprint as scope change. Jira recurring tasks compares the ways to schedule those.
Putting routine work in the backlog before planning also makes the velocity chart truthful, because work that is done without a ticket is work the chart never counts.
When the manual way is enough #
You do not need automation to keep a groomed backlog. It is enough, and simpler, when:
- The team is small and the product owner grooms continuously, a few items a day, and the top of the list is always ready.
- Sprints are long and stable, and refinement already has a fixed slot everyone protects.
- Nobody would read the ticket. If your team treats tickets for meetings as noise, a calendar invite and a saved filter will do.
What automation fixes is the specific case where refinement keeps being skipped, because nothing on the board says it was due.
Common questions #
Is backlog grooming the same as backlog refinement? Yes. Refinement is the term the Scrum Guide uses and many teams have switched to it. The activity is the same.
How far down should a groomed backlog go? About one and a half to two sprints of work. Grooming further down wastes effort on items that will change before anyone starts them.
Should the refinement session be in the sprint? If the team tracks it as a work item, yes: it is work the team does during the sprint, and putting it there makes a skipped session visible on the board.
Can Jira tell me which items are not groomed? Not directly, but a saved JQL filter on missing estimates and empty descriptions, like the one above, comes close, and a quick filter shows the same thing on the board.