Most dev teams use a backlog. Fewer plan by release. The structure you pick shapes how you think about work, and that ends up shaping what gets shipped.
A backlog is storage, not a plan
A backlog is a list of things that could be done. That's not the same as a plan for what will be done.
It starts useful — items are fresh, vaguely prioritised, connected to real intent. Then time passes. Eight-month-old requests sit alongside this week's bugs. The list grows faster than it shrinks.
Teams that manage from a backlog burn hours sorting, tagging, re-prioritising, archiving. None of that translates into anything shipping. The backlog becomes a maintenance obligation, not a planning tool.
What a release does that a backlog can't
A release has a scope and a shipping goal. Both matter.
The scope is binary. Work is in this release or it isn't. You can't defer the question forever the way you can with a backlog item — the release boundary makes it concrete.
The shipping goal changes the unit of progress. Not "tasks completed" but "release shipped." Fifty tasks done with nothing released is a different result than one release out the door with thirty tasks done. Releases reward shipping, not activity.
Why backlogs grow and releases ship
Adding to a backlog is free. Nothing constrains what goes in, which is by design — you want to capture without filtering. But the same property that makes a backlog easy to add to makes it hard to act from. Nothing in there has urgency unless you impose it. Nothing has a consequence for sitting still.
Releases work the opposite way. Adding makes the release bigger, potentially delaying it. The cost is visible, which keeps scope tight, which makes shipping possible.
Same team, two models
Backlog-first: 200 items. On a regular cadence, the team picks the top 10–15 by priority. Items near the top rotate based on customer requests and internal decisions. Shipping happens when enough items are done to constitute a version.
Release-first: The team names a release — say, "Feedback collection v1." Items go in until the scope feels right. Work proceeds until the release is done. It ships. Planning for the next one begins.
The second model has a clearer relationship between work and outcome. You know what you're building toward. You know when you're done. The definition of done exists before the work starts, not after.
You still need a backlog
The backlog doesn't disappear in a release-first model. It changes role.
It holds everything that's been considered but not yet scoped — ideas, bug reports, feature requests, future improvements. When it's time to plan the next release, you pull from it. Items move from "captured" to "committed."
This keeps the backlog healthier too. Because nobody is executing directly from it, the pressure to keep it perfectly groomed disappears. Rough ideas can sit. The release is where work is managed. The backlog is where ideas are kept. Conflating the two is where most teams get stuck.
If you publish what's coming next to users, the same release scope is what should drive a roadmap that doesn't overpromise.
That separation is the important part: releases hold scoped work, the backlog holds candidates, and the active release is where priorities and progress live. The active release is also the cleanest context to hand to an AI coding agent: not every idea you've ever had, just the work that is supposed to ship next.