Product Backlog

There has always been more to build than time to build it. The harder problem was that the candidates never sat in one place. A request from sales lived in a sales spreadsheet, a complaint from support lived in the support tool, an idea the founder mentioned in passing lived somewhere in a chat thread, and the cleanup a developer wanted lived in that developer's head. Four lists means four rooms where the order gets decided, and none of those rooms can see the others.

So the order usually went to whoever spoke loudest in the room. One sentence — "this one came from the founder" — was enough to push everything else down the list. The fact that three customers had asked for the same thing two months earlier wasn't written anywhere, so nobody could bring it up. The people whose requests slipped never heard why they slipped, and they came back the following month asking for the same thing again.

Another common state was a team working flat out while nothing visible shipped. Seven things started, none finished. Five people spread across seven open items move each one roughly a fifth of the time, so the first thing that could have shipped in two weeks lands a month and a half late and the other six are still open behind it. When candidates are scattered, it's hard to even count how many are in flight, and a number nobody can count is a number nobody can cut.

A product backlog merges the scattered lists into one and puts that one in order. The merge is half the value on its own, because once a sales request, a support complaint, and a developer's cleanup sit in the same place, they get compared on the same scale for the first time. The ordering supplies the other half. A single rule — take work from the top — leaves everything the team decided not to do sitting visibly at the bottom instead of quietly disappearing.

The terms grouped under the product backlog fall into three branches: how coarse a single entry is (unit), how the list is kept alive (activity), and how work that isn't a feature gets onto it (type).

Unit is the branch that decides how large a piece of work one line represents. Three of them stack.

1. Initiative — the largest container, holding several epics. "Rebuild the payment experience from scratch" is initiative-sized, big enough to occupy a quarter or half a year, so what gets written here is the state the team wants to reach rather than how anyone will get there.
2. Epic — a chunk of work that splits into several pieces. Under the payment initiative sit epics like card registration, refund handling, and receipt delivery. An epic usually runs for weeks, which means it won't finish inside a single cycle.
3. Task — an entry that has come down to a size someone can act on. One person can finish it in a few days, and it says what gets built and how.

Between epic and task sits the user story, a single sentence stating a requirement from the user's side — "as someone who has saved a card, I want to skip retyping the number on my next payment." The layers exist because work gets ordered at one moment and built at another. A quarterly plan is legible when ten initiatives are on the table; this week's development can't start until the same work has come down to tasks.

The fields on a single entry are fairly settled too. Five of them are standard.

1. Title — the one line that shows up in the list. Write it broadly, as in "payment improvements," and two months later nobody remembers what that line covered.
2. Background — why this is needed. Recording who asked and where the request came from gives the next reordering something to stand on.
3. Acceptance criteria — what has to be true for this to be finished. "A user who has saved a card does not retype the number on the next payment" works because anyone can judge it true or false in one pass.
4. Size — how big the work is. Whether it's a few days or a few weeks has to be settled before anyone can decide to pull it into this cycle.
5. Position — where the entry sits in the list. The other four describe the entry itself; this one describes its relationship to everything else.

Acceptance criteria is the field that goes missing most often. Start building without it and the argument arrives after the work is done, in the form of "I assumed this part was included too," and that conversation costs another week. Entries that need more detail than a list row can hold get a product requirements document (PRD) of their own, and the backlog entry keeps nothing but the path to it.

Activity is the work of keeping the list alive, and backlog refinement is the term that sits here. Every week or two, for about an hour, the team fills in descriptions near the top, sizes the entries, and revisits the order. Deleting entries that were filed six months ago and mentioned by nobody since also happens here. Teams that find deletion painful end up with 300 entries, and past that point nobody reads from the top any more, which makes having a list indistinguishable from not having one. Refinement only needs to reach the top twenty or thirty entries. Anything lower is likely to move anyway, so polishing it now just means polishing it again later. A refinement session that keeps running over is usually a team trying to repair the whole list in one sitting rather than the part it is about to use.

Type covers how work that isn't a feature gets onto the list at all. The tech debt ticket is the main example. It adds no visible screen, so unless it's on the list it loses to new features every single time. Putting it in the same list in the same format forces it to compete for position like everything else. Many teams also reserve a fixed share of each cycle for it in advance — if a cycle holds 30 units of work, 6 of them stay blocked out for structural cleanup. Without a declared share, that space is the first thing surrendered whenever something urgent arrives, and after half a year of that the time it takes to add any new feature climbs noticeably.

Merging the three branches doesn't sort the list by itself. What belongs at the top is the job of prioritization. And the slice taken off the top of the sorted list, sized to one cycle, is the sprint backlog. The product backlog persists; the sprint backlog appears and disappears with the cycle.

Who writes it and who reads it is settled as well. Exactly one person decides the final order — the product owner on teams running scrum, the product manager everywhere else. Anyone can file an entry, and entries arriving from many directions is a good sign rather than a problem. But two hands deciding the order is the same thing as having two lists. Reading is much wider. Engineering and design read it to see what's coming, sales and customer success read it to find an answer for a customer, and executives read it to confirm what the quarter has ruled out. Because the purposes differ, so do the places people look: engineering and design read the top ten or so, sales hunts for the position of the entry they filed, and executives scan the stretch that got pushed down. A list therefore has to work both for someone reading from the top and for someone arriving to find one specific row.

"That request is in the backlog, but it's eighteenth right now. It won't happen this quarter."

Not a refusal — a position report, with an unspoken invitation to bring something to move down if you want it moved up.

"This epic hasn't been broken up yet, so we can't take it this cycle. Let's cut it into tasks at refinement."

Anything larger than a cycle can't go into a plan, so split it first.

"The acceptance criteria are empty. Start like this and we'll be having this conversation again after it's built."

A required field is missing, and ten minutes now saves days later.

At Pagedeck, Mia opens the list every other Wednesday afternoon and reads down from the top. When Theo says something like "this one touches notifications too, so it's bigger than it looks" while sizing an entry, the entry splits in two right there and each half is placed again. Noa marks the entries that need a screen so design lands in front of engineering rather than behind it.

Sofia brings customer requests to the same meeting. Said out loud, a request ends with that day's conversation; filed as an entry, it enters the competition for position. When the same request shows up from three customers, that history accumulates on the entry and becomes the argument for moving it up at the next refinement. This list is also what Mia pulls up when Grace asks about the quarterly plan, and most of that conversation goes not to the handful of things the team chose but to why twenty-odd entries are sitting below them.

The most common mistake is reading the backlog as a list of promises. Something is on the list, so it looks like a commitment to build it eventually, and the person who filed it expects exactly that. In practice most entries below the top never get built, because the list exists to gather candidates for comparison rather than to hand out queue numbers. Reading it as a promise breaks two things at once. The person who filed an entry sees no news six months later and stops trusting the list, while the person maintaining it finds deletion socially expensive and keeps carrying dead rows. Saying "we're not doing this" at refinement and closing the entry is better for both sides, and it costs less than it feels like it does: the person who filed it would rather hear no in month one than hear nothing in month six.

The second mistake is believing a longer list means better management. It looks like evidence that no idea was ever lost, which is a reasonable enough reading. But a list is worth what it says when you read from the top, not what it holds in total. Finding the top ten rows in a 400-entry list means re-reading the list every time, and that friction pushes people back onto memory instead of the list. At that point the team is exactly where it was with four scattered lists. Deleting old entries costs almost nothing, because a request that genuinely matters always comes back.