What is a Backlog?
Backlog
A backlog is a ranked list of everything a team has identified as worth doing but hasn't started yet, ordered so the most important work sits at the top.
A backlog is the full list of work a team has identified but hasn't started, ranked so the most important item sits at the top. The term comes from Scrum, where the product backlog holds every feature, fix, and idea a team might build, but the concept applies far beyond software: an agency's backlog might hold client requests, internal improvements, and content ideas, all waiting for their turn.
A backlog is not the same as a to-do list. A to-do list is what you're doing today. A backlog is everything you might do, in the order you'd do it if you had unlimited time tomorrow. Items move from the backlog into an active sprint, a day's plan, or a project only when the team commits to starting them.
For a small agency or studio running several clients at once, the risk isn't having a backlog. It's letting it turn into a graveyard: hundreds of items nobody has looked at in months, mixed in with the two or three things that actually matter this week. A backlog only earns its place if someone keeps it ranked and someone reviews it on a schedule.
Product Backlog, Sprint Backlog, and Bug Backlog
Teams often run more than one backlog at a time, and mixing them up causes confusion:
- Product backlog - every feature, improvement, and idea for a product or service, ranked by priority, with no fixed timeframe attached
- Sprint backlog - the smaller subset pulled from the product backlog for the current sprint, scoped to what the team can finish in that window
- Bug backlog - defects and fixes, usually ranked by severity and user impact rather than business value
- Content or request backlog - for agencies, client requests, content ideas, or internal improvement tasks that haven't been scheduled yet
Backlog vs To-Do List
A to-do list and a backlog look similar (both are lists of things to do) but serve different jobs. A to-do list covers what one person is doing today or this week; it disappears once the tasks are done. A backlog covers everything a team might do, ranked and revisited over months, and it never fully empties. New items get added faster than old ones get finished; that's normal. A healthy backlog isn't a backlog that shrinks to zero. It's one where the top of the list stays clear and current.
How to Prioritize a Backlog
Ranking a backlog is the part teams skip, and it's the part that makes a backlog useful instead of a pile. Three methods cover most situations:
| Method | How it works | Best for |
|---|---|---|
| MoSCoW | Sort items into Must have, Should have, Could have, Won't have | Fast triage with a large backlog |
| Value vs effort | Plot each item on two axes and favor high value, low effort | Comparing dissimilar items |
| Weighted scoring | Score each item against fixed criteria (impact, urgency, cost) and rank by total | Teams that need a defensible, repeatable process |
Backlog Refinement: Keeping It Usable
Backlog refinement (also called backlog grooming) is a recurring session where the team reviews upcoming items, breaks large ones into smaller pieces, adds missing detail, and drops anything no longer relevant. Without it, a backlog rots: old items sit at the top because nobody re-ranks them, and new items pile up underneath without enough detail to act on.
Most teams run refinement weekly or every two weeks, for 30-45 minutes, timed to land a few days before the next planning session. Three questions cover most of the work: is this item still worth doing, is it sized small enough to estimate with confidence, and does it have enough detail that someone other than the person who wrote it could pick it up?
- Run refinement on a fixed schedule, weekly or biweekly, not "whenever there's time"
- Cap it at 30-45 minutes: refinement drifts into a design meeting if left open-ended
- Break down anything estimated at more than 3-4 days before it enters a sprint
- Archive items untouched for more than 2-3 months instead of letting them scroll forever
How Big Should a Backlog Get
There's no fixed ceiling on backlog size, but there's a practical one: only the top 2-4 weeks of work needs full detail. Items further down can stay rough, described in a sentence rather than fully specced, because priorities shift before they're reached anyway.
A backlog with 300 untouched items isn't a sign of a busy team. It's a sign the ranking has stopped happening. If an item has sat unranked and untouched for more than a quarter, either schedule it or remove it. A shorter, current backlog beats a long, stale one every time someone has to find what to work on next.
A Worked Example: Backlog for a 10-Person Agency
A 10-person agency running three active clients might keep a single shared backlog with items tagged by client, ranked together so the team can see everything competing for the same hours:
| Item | Client | Priority | Estimate | Status |
|---|---|---|---|---|
| Redesign homepage hero | Acme Co | High | 3 days | Ready for sprint |
| Add SSO login | Acme Co | Medium | 5 days | Needs refinement |
| Fix checkout bug #482 | Beta Inc | High | 4 hours | Ready for sprint |
| Migrate blog to new CMS | Beta Inc | Low | 8 days | Parked |
| Quarterly brand refresh | Studio internal | Medium | 2 weeks | Needs refinement |
In Melororium
Build and prioritize your backlog in Melororium
Common mistakes with backlog
What teams get wrong most often, and what to do instead.
- 1
Letting the backlog become a dumping ground
Adding every idea, request, and half-formed thought without ever removing anything. A backlog that only grows stops being a planning tool and turns into an archive nobody trusts.
- 2
Marking everything as high priority
Ranking is only useful if it separates items. When ten items are all "urgent," the label has stopped meaning anything, and the team is back to picking work by gut feeling.
- 3
Keeping the backlog in one person's head or inbox
A backlog that lives in a project manager's email folder isn't a team backlog. If the rest of the team can't see it, they can't help prioritize it or flag what's missing.
- 4
Never removing stale items
Leaving requests from two clients ago sitting at the bottom of the list. They add scrolling, not value, and make it harder to trust that everything visible is still worth doing.
Frequently asked questions
Who should own the backlog on a small team?
One person, usually a project manager or team lead, should own the ranking, even if the whole team contributes items and joins refinement sessions. Shared ownership with no single decision-maker tends to produce a backlog where nothing ever moves to the top.
What's the difference between a backlog and a roadmap?
A backlog is the full, granular list of individual items a team might work on. A roadmap sits above it: a smaller set of themes or deliverables with a rough timeframe, aimed at communicating direction rather than listing every task.
How often should a backlog be refined?
Weekly for fast-moving teams, every two weeks for most others. The exact cadence matters less than having one; a backlog reviewed on no schedule drifts out of date within a month.
Can a backlog be too short?
Rarely a problem in practice. A short backlog usually means the team is estimating and starting work quickly, not that they've run out of ideas. It becomes a problem only if the team is regularly out of ready work between planning sessions.
Does Melororium have a backlog view?
Tasks in Melororium can sit in a board column before they're scheduled, tagged by project and priority, and pulled into active work when the team is ready. Bulk actions let admins re-rank or move a batch of items in one pass.
