Skip to content

Groom the backlog

Pro plan Project Member

The backlog is every task in the project that is not assigned to a sprint: the pool you draw from when planning a sprint. The Backlog tab shows it as a sortable table built for triage, with inline edits, grouping, and bulk moves.

By default the table shows top-level tasks only. If the project has subtasks, a Roots only / All tasks toggle appears in the toolbar; switch to All tasks to include unscheduled subtasks, each with a breadcrumb showing its parent.

Single task:

  1. Find the task’s row. The Sprint column has a Move to… dropdown listing the project’s open sprints (those still in Planning or already Active).

  2. Pick the sprint. The task leaves the backlog immediately.

Several at once:

  1. Tick the checkbox on each task you want to move. The header checkbox selects everything currently listed.

  2. A bar appears above the table showing how many tasks are selected. Choose the target in the Move to sprint… dropdown.

  3. Select Move.

  • Group by organizes the table under collapsible headers by Status, Priority, or Assignee (or No grouping for a flat list). Your choice is remembered per project.
  • The column headers sort by title, priority, assignee, or due date.
  • Filter narrows the list by status and priority, and the search box matches task titles.
  • You can save a combination of filters, sort, and grouping as a named view and reapply it later from the toolbar.

Each row supports quick edits without opening the task: priority is an inline dropdown, and clicking the row opens the full task form. Overdue due dates show in red. For everything you can do inside the task form itself, see working with tasks.

The Columns menu toggles the Priority, Assignee, Due date, and Sprint columns on and off. Hiding the Sprint column also hides the per-row Move to… dropdown, which makes for a cleaner read-only review. Column choices persist in your browser, so the backlog looks the way you left it next time you open it.

Tasks that belong to an epic show a colored epic chip under their title, which makes theme-by-theme grooming easy to scan. The Epics button in the toolbar manages the project’s epics; see grouping work with epics.

  1. Groom weekly, not just before sprint planning. A half-hour every Friday keeps the backlog scannable; a two-hour session right before planning ends up rushed. The weekly cadence also catches things while they’re fresh — “we need to break this big task in half” is a 2-minute call when you remember why, a 20-minute archaeology session three weeks later.
  2. Always estimate tasks during grooming. Estimation is the moment to ask “is this still real? is the scope right? what’s blocking it?” An unestimated backlog task is one the team hasn’t actually thought about. The discipline of “no unestimated tasks in the backlog” forces the conversation before sprint planning, not during.
  3. Break tasks over ~16 hours into subtasks. A task that big tends to drag across sprints. Split it during grooming so each piece fits inside a single sprint commitment. The Sprint board automatically pulls the parent when a subtask is added, so the structure survives planning.
  4. Use grouping by Priority for triage; by Epic for theming. Two different conversations, two different views. “What’s most urgent?” — group by priority. “What work belongs to the Q3 migration theme?” — group by epic. Save both as named views.
  5. Don’t archive an unestimated task — estimate first. “Old” tasks sometimes get archived because no one estimated them. The right move is to estimate and either schedule or close. Archiving without that conversation accumulates skeleton tasks no one understands.
  • The Move-to-sprint dropdown is empty. No open sprints exist (every sprint is Completed, or none have been created). Plan a sprint first.
  • My subtask isn’t appearing. The default view is Roots only. Toggle to All tasks in the toolbar. Each subtask shows its parent as a breadcrumb so you can see what it belongs to.
  • I selected 50 tasks and bulk-moved them but only 20 show in the sprint. Two causes: (a) the other 30 had parent tasks already on a different sprint, and Onplana declines to move them without confirmation; (b) the permission check refused some of them (you don’t have edit on certain tasks). Check the move-confirmation dialog and any error toasts.
  • The backlog table feels slow with hundreds of tasks. Apply a filter (status: To Do, priority: High, or similar) to reduce the rendered count. The data is paginated server-side, but rendering hundreds of rows with inline controls is the bottleneck.
  • A task I moved to a sprint shows back in the backlog. The sprint it was on was probably deleted (which sends tasks back to the backlog). Re-add to a different sprint.
  • Backlog + Sprint planning. The backlog is the pool; sprint planning is where you take a slice of it. The Backlog tab is for triage and groom; the Sprint tab’s “From Backlog” picker is for the actual commitment. See Plan a sprint.
  • Backlog + Epics. Epics let you theme backlog work. A “Q3 migration” epic groups every related task across the backlog; the backlog table shows the epic chip on each row. Group by epic during grooming to plan a sprint around an epic. See Group work with epics.
  • Backlog + AI assistant. Ask “what’s in the backlog for <project>?” or “summarize unscheduled high-priority tasks”. The assistant reads the same data the table shows. See Chat with Onplana AI.
  • Backlog + Bulk-edit. Multi-select multiple rows to bulk-update priority, assignee, or status — the same toolbar that bulk-moves to sprints lets you bulk-set other fields. Faster than opening each task.
ToolMapping
Jira backlogDirect concept; same Sprint/Backlog separation
Linear backlogDirect; same triage and grouping
AsanaAsana lacks a formal backlog; sections approximate it
TrelloCards in “To Do” column ≈ backlog
ClickUp”Sprint Folder” lists serve as backlogs

Why is a task missing from the backlog? Either it is already on a sprint, or it is a subtask and the toggle is set to Roots only. Switch to All tasks to see unscheduled subtasks too.

Does moving a subtask move its parent? Not from the backlog table; the row you move is the row that goes. The sprint board’s Add from Backlog picker is the surface that pulls parents along automatically when you select a subtask.

Are my grouping and column settings shared with teammates? No. They are stored in your browser, so each person grooms with their own layout.

How big should a healthy backlog be? Roughly 1-3 sprints of work, plus an “icebox” of bigger ideas. A backlog of 200+ unestimated tasks is signal: either prune via the archive action, or estimate them. The team mental-model breaks above ~30 active backlog items.

Can guests groom the backlog? Members and above can groom; Guests have read-only access to projects they’re explicitly added to. If a guest needs to contribute backlog items, the cleanest pattern is via intake forms.

Does grooming a backlog affect velocity calculations? Indirectly: a well-groomed backlog with accurate estimates produces sprints that finish at the commitment, which builds a healthy velocity signal. A backlog of “guess the estimate” tasks makes velocity bounce around.

Can I see backlog history? Each task has its own activity log, but there’s no per-backlog audit of “what was added when”. The Reports builder can approximate this by filtering on the Tasks entity with a sprint=null clause and a created-date range.