Sprint Backlog vs Product Backlog: What Goes Where

A sprint backlog is the set of product backlog items the team picked for the current sprint, plus the plan for delivering them. The product backlog is the ordered list of everything else that might get built later. If a piece of work isn't needed to meet this sprint's goal, it stays off the committed list.

Teams blur that line in a few ways: they pull in "small" extras, leave leftovers unlabeled, or treat the product backlog as an unordered parking lot. Below is the rule for what goes where, with one example you can copy.

Sprint backlog vs product backlog

The Scrum Guide treats these as two separate artifacts. The product backlog is emergent, and the product owner orders it. The sprint forecast is what the developers believe they can finish in the sprint, aimed at one goal.

	Product backlog	This sprint's list
Time horizon	Now through later, often months	This sprint only
Who orders it	Product owner	Developers, inside the sprint goal
What it holds	Features, fixes, debt, research, ideas that survived triage	Selected items plus a delivery plan
Change rule	Reordered when you learn something	Scope can be clarified, but nobody swaps the goal without saying so
Done when	An item is ready to select, or is dropped	The sprint ends and unfinished work is rolled or cut on purpose
Success signal	The top is the next thing you would fund	The sprint goal ships as a usable increment

Putting a sprint name on a long wishlist doesn't commit anyone to it. A short list sized against real capacity does.

What each list is for

The product backlog tells you what to do next. The committed list tells you what you will finish before this sprint ends, and how. When the two get mixed, the team starts ten items and finishes three, or planning day turns out to be the first time anyone ordered the work.

What belongs on this sprint's list

Put an item on the sprint backlog only when all of these are true:

• It serves the sprint goal. If you can't say which part of the goal it serves, it's a candidate for later.
• It's small enough to finish inside the sprint, or it's a first vertical slice with a definition of done the team can meet now.
• Someone can start it. Items with open questions, missing designs, or blocked accounts stay on the product backlog until they're ready.
• The team has room left after support, reviews, and a buffer for interrupts. A plan that uses every hour will slip.
• The product owner and the developers agree on the acceptance bar. "Make onboarding better" is a theme. "New accounts can invite a teammate without emailing support" is an item.

Write down the plan, not only the tickets. A few implementation notes, a test list, and who starts first are enough. A developer who missed planning should still be able to see the path to done.

Bugs in work you've already selected stay with that work. Production bugs go to the product backlog unless they threaten the sprint goal or a promise already made to a customer. Write that exception down, or every alert turns into an unofficial replan.

What stays on the product backlog

Leave it on the product backlog when:

• It's valuable, but not part of this sprint's goal.
• It still needs a spike, a design, or a decision from outside the team.
• It's larger than a sprint and nobody has sliced it yet. The parent stays put, and only the slice you will finish moves.
• It came in from a call, a Slack thread, or a support ticket and has been triaged but not ordered. Writing something down isn't a commitment to do it.
• It's unfinished work from last sprint that you won't put ahead of the new goal. Rolling it forward without a fresh decision hides a missed forecast.

Order the top and leave the bottom rough. Item forty doesn't need an estimate. The next sprint or two should be clear enough that planning selects work instead of discovering it.

Ready versus committed

Ready means an item can be pulled. Committed means it was pulled for this sprint. If you mark half the product backlog ready and then select all of it, you've just renamed the product backlog. Ready is a quality bar (the outcome, acceptance notes, and named dependencies). It isn't a date.

One backlog and sprint, as a real week

Here is one backlog and sprint for a six-person team working on a B2B workspace. The sprint is ten working days. The goal: a new customer can submit a request and see it become a tracked ticket without a developer in the loop.

Selected for this sprint:

1. A public form creates a ticket with the right type and the first stage.
2. The requester gets a status link that doesn't need an account.
3. Duplicate submissions from the same email within an hour collapse into one ticket.
4. Fix the staging-only failure that blocks the form's file upload.
5. A short internal note on how support should answer "where is my request?"

Left on the product backlog, in order:

1. Slack messages become tickets. Valuable, but a second channel would blow the goal.
2. Meeting notes become reviewed tickets. Next sprint if the form ships.
3. Custom stages per ticket type. Needed soon, but not needed to prove the form works.
4. A cycle-time view of this workflow. Useful once there's data.
5. An empty-state redesign that came out of a sales call. Not ordered above the workflow.

Capacity (an illustration, not a benchmark). Over the last three sprints the team finished about 28, 31, and 26 points, and lost about two days a week to support. They select 24. If the upload fix grows, deduping gets cut first, and they agree on that during planning.

What they turn down. A founder asks to add "just the Slack parser, it's small." The product owner repeats the goal and points to that item, which is still below the line. It stays next. Saying no only works if people remember what the goal is. A sprint goal the team still remembers on day six is what you're protecting when you do.

How work crosses the line

Items cross during planning. A good sprint planning session confirms the goal, selects items that fit capacity, and sketches the plan. Sprint poker helps when the team disagrees on size, but it wastes the hour if the item is still vague. Send a vague item back to the product backlog instead of inventing a number for it.

During the sprint, developers can add, split, or drop tasks as they learn. Adding a new product feature because it's "related" is a scope change, and the product owner decides whether it replaces something already selected. Keep both items visible so the forecast stays honest.

When the sprint ends, every unfinished item gets a decision: roll it and say what it displaces, split the remainder back onto the product backlog, or drop it. Reviewing rollover like this keeps the backlog in sprint from turning into a junk drawer. If a board carries every open card forward, the team learns that "selected" just means "still open somewhere."

Jira, Linear, and a spreadsheet can all hold both lists. They all fail the same way, too: cards get dragged across with no goal and no capacity check. The tool can't make that decision for you.

Who decides

The product owner orders the product backlog and sets the sprint goal with the team. The developers decide how much they can pull and how they'll do the work. A manager, a salesperson, or a loud Slack channel can propose work, but none of them gets a private door into the current sprint. When planning runs long, it's usually because nobody ordered the top of the product backlog the day before. Whoever facilitates keeps asking "does this serve the goal, and does it fit?" until the answer gets boring.

Mistakes that collapse the two lists

Selecting everything marked ready. Being ready gets an item considered. Capacity decides whether it enters the sprint. Velocity is a noisy ceiling, so subtract known interrupts, and don't treat it as proof the goal was met.

Hiding leftovers. A card that has been in progress for three sprints is unpaid debt with a status label. Put the remainder on the product backlog at its true priority, or kill it.

Two competing tops. A roadmap deck, the product backlog, and whatever engineering has already started can't all be the plan. Keep one ordered list and treat the roadmap as a view of that list over time.

Tasks with no parent. "Update copy" is a plan step. If tasks are the only rows, you can't tell whether the goal is on track.

Using the sprint as the inbox. Triage new work onto the product backlog the same day. Promoting it into the sprint is a separate decision.

A sprint planning template that starts with capacity, then the goal, then the selected items makes these slips easy to spot. It's a checklist, though. The team still makes the call.

Ten minutes at the end of planning

1. Read the sprint goal aloud. Remove any selected item that doesn't serve it.
2. If the selected total is above a recent pace (after time off and support), remove whole items until it's under.
3. Confirm each item can finish this sprint rather than "continue next time."
4. Name the first item you'll drop if something overruns.
5. Agree that the top five items still on the product backlog really are next.

With the line drawn this clearly, most of the mid-sprint arguments go away.

Where a workspace helps

Any board can show two lists. The trouble starts earlier, when a Slack message, a call, or a production error jumps straight onto the current sprint and the product backlog never gets a say.

Falrow makes that path explicit. Those inputs become tickets, and a person still triages them onto an ordered list before a cycle starts. Cycles set the schedule, and someone reviews the rollover so the board doesn't carry every open card forward.

Forecasts don't choose the goal. Cycle time, cumulative flow, and a Monte Carlo forecast only show whether the amount you selected looks like what you've delivered recently. Keeping the two lists separate is up to you, whatever tool you use. Falrow is in private beta, with access and pricing on request.

FAQ

Is the committed list the same as the product backlog?

No. The product backlog is the ordered inventory of future work. The list for this sprint is the subset you selected, plus the plan to deliver one sprint goal. When the sprint ends, that list is finished as an artifact. Unfinished items go back to the product backlog, or move into the next sprint by an explicit decision.

Can you add work to the sprint backlog after planning?

You can add tasks needed to finish what you already selected. A new feature is a scope change: either something else comes out, or the team says openly that the forecast grew. The product owner owns that trade-off. Silent additions are how a ten-day sprint becomes a fifteen-day sprint with the same name.

What happens to unfinished backlog in sprint?

Each unfinished item needs a decision at the sprint boundary: roll it, split it, or drop it. Leaving it in progress on a board that rolls forward hides the miss and takes capacity from the next goal. The next selection still has to fit the new goal and the team's real capacity.

Who can change what is in the current sprint?

Developers own the plan and update tasks as they learn. The product owner owns the goal and any change to which product items are in or out. Stakeholders bring requests to the product backlog and don't edit the current sprint directly. That boundary stops a commitment from turning into a queue.