Short answer: The product backlog is the full ordered list of everything that might be built, owned by the PM, continuously refined. The sprint backlog is the small subset committed for the current iteration, owned by the team, frozen for the window. The product backlog answers what comes next over months. The sprint backlog answers what comes next over fourteen days. Most teams that struggle with either are actually struggling with backlog hygiene — order, acceptance criteria, and the rule against mid-sprint additions.
The product backlog consists of everything that might get built. Indeed, it is always ordered and ranked top-to-bottom by the PM. The sprint backlog is a small selection of items the team aims to deliver in the current iteration. That’s the whole point.
If the answer is so simple why are there a hundred articles online regarding the same? The two backlogs are simple to map out but difficult to manage. Although most teams have both a delivery manager and a project manager, at least one of them is probably failing.
This unfurling guide is the one we’d share with a team that’s confused about which backlog owns which work. We are going to look at the working definitions of each backlog, who owns each backlog, how items move between backlogs, the five rules that keep either backlog functional, and when running both is the wrong move. If you want the canonical definitions, the Scrum Guide spells out the two artefacts plainly; this article is the operational layer on top.
A working definition of both
Product backlog - a list of everything the team might build, ordered top-to-bottom by the product owner. This story should be detailed and ready to pull into a sprint. The stories located at the bottom indicate that they are rough and need work before they can be delivered. The backlog spans across months. The order belongs to the PM.
Sprint backlog refers to the items from the product backlog that the development team has committed to delivering during the current sprint. During sprint planning, items are selected and remain frozen for the sprint duration. They are then ticked as they move to accepted in the workflow. The sprint backlog exists for a duration of two weeks. The responsibility lies with the team.
There’s only one former: the pop the product backlog flows top-down into the sprint backlog at planning, the team works through the sprint backlog, the sprint backlog dries up as stories get Accepted and the next sprint pulls fresh stories from the top of the product backlog. Repeat.
The two are separate artefacts as one is more volatile than the other. Continuous changes in product backlog are encouraged through reordering and refining process. The sprint shouldn't change once it begins, as the commitment is not a guarantee but it does need to hold. When used together, we get a sprint that quietly increases in size by 30% halfway, or a product backlog that nobody will touch in case it breaks the team plan. Not uncommon to see both.
Who owns what
Properly running practices within any team cannot alter the ownership split.
The product manager has final say on product backlog order, refinement, and what’s next. Items may be requested by stakeholders; placements decided by PM. Engineers can flag missing items; the PM determines whether they are legitimate and where they sit. The PM is the sole human who takes the responsibility of answering what the team should build next.
The sprint backlog belongs to the entire team. Upon selection during planning, the team takes responsibility for its completion. The Product Manager cannot add new stories during the sprint. The team must not drop stories they signed up for without a word. If a story cannot possibly fit, the story is explicitly bumped back. This is done with a one-liner retro note as to why.
There are two predictable ways this split breaks. The team agrees to incorporate a small story into the sprint backlog during the iteration by the PM. Now, the sprint commitment is meaningless. The team treats the product backlog as a shared editing surface anyone can reorder. The project manager is no longer the owner of priority; both of these failures destroy the discipline. A discipline of backlog which holds for ten weeks but breaks in week eleven is no different from no discipline at all.
How stories move between the two
The lifecycle of an individual story, idealized.
- Created in the product backlog. Often as a rough sketch — a problem statement, an opportunity, a stakeholder request. Sits low until refined.
- Refined. The PM (often with engineering input) sharpens the story: acceptance criteria, points, dependencies. Once refined, it's "ready" — eligible to be pulled into a sprint.
- Moved up the product backlog. As priorities clarify, the story rises toward the top. The PM owns the order.
- Pulled into the sprint backlog at planning. The team commits to it as part of the sprint.
- Worked, finished, delivered, accepted. Story moves through the workflow inside the sprint.
- Dropped from both backlogs. Done. Out of the system.
Stories that are not accepted by end of the sprint should be returned to the product backlog (along with any retro context), not automatically to the backlog of the next sprint. It is a tiny and crucial rule. When we auto-roll unfinished stories, we create growth in the team's commitment that is invisible. A forcing function is the question of whether the team accepted to do it in that Sprint. Atlassian's overview of how a backlog actually works in practice puts the same point a different way.
For details on splitting and refinement, see principles of effective story writing.
The rules that keep either backlog from rotting
Five guidelines. We've observed how teams have failed over the last 20 years, and each of these observations seeks to prevent one of those failures.
The product backlog is a list ordered to a single ordering top to bottom and does not have parallel boards. This is not a kanban with priority lanes. Not a multi-board portfolio. A singular list. The team draws its members from the best talent available. When your PM tool has four backlog views, and three aren't in sync - the problem lies with the tool and you've already lost.
Each story at the top has acceptance criteria; here "top" refers to the next 2-3 sprints’ worth of stories. Acceptance criteria convert a story from a problem message into something the team can actually complete. Stories that are not equipped with clear criteria are not ready for pulling, even if the PM wants them right away. There's a healthy amount of backlog refinement and an unhealthy one; aim for the former.
Rule 3: The sprint backlog cannot change. No story may be added mid-sprint without a conversation that explicitly abandons the original commitment. Crises are real; treat them as real, not routine. A team that quietly accepts three new stories every sprint is making an empty commitment.
Rule 4: Grooming is different from sprint planning. We use grooming to improve and reschedule the product backlog. Planning Makes Commitments to Sprint When you combine grooming with planning, planning takes three hours and the team leaves wondering what they signed up for. The product-manager-facing version of this is in grooming your backlog: the skills every PM should master. For the practice as a whole, see the ground rules that keep a software project on track.
In accordance with rule 5, a velocity is only counted for accepted stories. If what meets the engineering definition of done, then the sprint backlog is a record of participation. If what meets the PM definition of done, then the sprint backlog is a record of everything shipped to customers. By default, LiteTracker enforces this; most generic PM tools permit you to configure your way around it.
Teams adhering to five rules have productive backlogs. When teams violate two or more of the four rules, they almost always suffer from one of the failure modes.
Common failure modes — and what they signal
The most common four failures we see, and what is really broken in each case.
The product backlog turns into the team’s haven to dump their prized requests and asks. Essentially, the Product Manager hasn’t created a pressure to dodge new assignments, or the engineering team is not feeling safe saying no. The solution is to agree on the rule in the retro meeting and then uphold it. The PM will give up after a quarter.
The product backlog tiene 400 items y nadie puede encontrar nada. Señal: se agregan items, pero nunca se quitan. Underlying Problem: Absence of Icebox Practice Solution: Add a New Icebox Column. If items are below a clear cutoff they are not in the backlog anymore; they are parked — see defrosting your icebox for the mechanics. The real backlog is the top 30 items.
For pulled-in stories too, do work to avoid "this is not what I imagined" outbreaks. Or fix: there the work acceptance criteria not there. The main reason behind it is grooming is skipped or rushed. A sprint backlog is not complete unless every story within it has acceptance criteria. No exclusions. The team's sprint velocity will reduce for two sprints and stabilise after that.
Teams have multiple backlogs competing with each other. The sign of this problem is that a feature lives in three places with three different orderings, and the team is confused about what to work on. The real issue is consistent coordination, not tooling itself. To resolve this issue, create a master backlog that is owned by a single PM. The team-specific labels or views will pull from this master backlog. Have no parallel backlogs; try to reconcile weekly only.
This pattern is exactly what LiteTracker is built around; one ordered backlog, accepted-only velocity, frozen iteration. What is present are those 20 percent of features, which drive 80 percent of results; what’s not is the configuration surface that allows teams to cheat the discipline.
When running both backlogs is the wrong move
The split of product/sprint backlog means a team runs sprints. You do not require the split unless you are sprinting.
- Pure Kanban teams have a single pull-based backlog with WIP limits — the Kanban Guides definition is concise about this. There's no sprint commitment, so there's nothing to split out. The "ready" portion of the backlog is what's pull-able; the rest is unfinished refinement.
- Continuous delivery teams with very short batch sizes sometimes run one ordered queue with no formal sprint. Same shape as Kanban; the "sprint backlog" doesn't exist because the iteration window doesn't exist.
- Teams under three engineers rarely benefit from formal backlog separation. A single ordered note works fine. Adding the second artefact is overhead at this size.
We make a distinct separation between output and outcome metrics. You don’t need two backlogs if you don’t have sprint commitments. A single ordered queue suffices.
We say this as a company that tracks. We don’t need a two-backlog model if your team of two engineers are shipping fine with a list on Trello. The forcing function we provide only pays for itself when the team is big enough to require one.
Frequently asked
What's the difference between a product backlog and a sprint backlog?
The product backlog represents everything that may be built. The lists are ordered based on relative importance. It belongs to the Product Manager and is continuously refined over the months. The sprint backlog consists of the small subset of items that the team has committed to delivering in the current sprint. It is owned by the team and it is frozen for the two-week window of the sprint. During the sprint planning, the product backlog is filtered down into sprint backlog.
Who owns the product backlog?
The product owner. The PM manages organization, improvement, and future decision-making. The ones the PM decides to place on the backlog. When multiple people can reorder the backlog, nobody owns priority really.
Who owns the sprint backlog?
The group. After making selections during planning, the team collaborates on the completion of committed stories. The team doesn’t drop stories; the PM doesn’t add them mid-sprint. Any stories that don’t fit should be explicitly bumped to the product backlog with retro context.
How often is the product backlog refined?
Please refer to the section on the Product Backlog for more information. Top items should have acceptance criterion and be ready to pull. Items that are at the deeper end may remain as sketches unless and until they rise towards the surface. Refining is PM’s standing work. It is not a one-off event.
Can items be added to the sprint backlog mid-sprint?
Not in that case. Inserting new items mid-sprint breaks the commitment, makes velocity ineffective as a forecasting tool, and shows that the PM does not have a forcing function against new asks. Real emergencies should be the exception. They should be treated as emergencies i.e. abandoned original commitment, retro it. Not routine.
What's backlog grooming?
Refining a product backlog requires writing acceptance criteria, splitting larger stories into smaller ones, prioritizing them, and removing items that no longer matter. Grooming is a meeting that happens every week. It is distinct of sprint planning.
Does Kanban have a sprint backlog?
No. Kanban has a continuous pull mechanism, with a single backlog having WIP limits; there isn't a sprint commitment and backlog. The “ready” part of the backlog conceptually plays a similar role (items eligible to pull) but is not a frozen commitment for a fixed window.
What happens to unfinished sprint backlog items?
They go back to the product backlog with retro context. They do not automatically roll into the next iteration as that hides slip. A story staying unfinished often leads to this conversation in the retro. Why? Because it must be too big, acceptance criteria are hazy, or it has hidden dependencies.
Still stuck
If you have a single backlog that is ordered, the PM owns the order, every top-of-backlog story has acceptance criteria, and the commitment is for two weeks, you are doing the product/sprint split correctly. Everything else is just maintenance.
In case you want a tool that defaults to one ordered backlog, accepted-stories-only velocity and frozen iteration commitments, that's what LiteTracker is for. There are unlimited users in the free tier. The imports take a minute. If you are running a Kanban system, or have under 3 engineers, save your money and skip us – you aren't deriving enough value from the two-backlog model.
Don't maintain two backlogs under any circumstances. Conduct them because the mandatory driver is self-financing.