Product Backlog vs Sprint Backlog

The Product Backlog is the ordered list of everything that might improve the product, and the Product Owner is accountable for it. The Sprint Backlog is a plan for one Sprint, made by and for the Developers: the Sprint Goal, the Product Backlog items selected to meet it, and the plan for delivering them. The Product Backlog lasts as long as the product and changes whenever the Product Owner learns something. The Sprint Backlog lasts one Sprint and changes as the Developers learn how the work is going, but never in a way that endangers the Sprint Goal. The Increment is what comes out: finished work that meets the Definition of Done.

What the Scrum Guide says about each

The 2020 Scrum Guide↗ (opens in a new tab) names three artifacts, and gives each a commitment that says what progress is measured against. For the Product Backlog it is the Product Goal. For the Sprint Backlog it is the Sprint Goal. For the Increment it is the Definition of Done.

• Product Backlog. The guide calls it an emergent, ordered list of what is needed to improve the product, and the single source of work undertaken by the Scrum Team. Its commitment, the Product Goal, describes a future state of the product that the team plans against, and the team must fulfil or abandon one Product Goal before taking on the next.
• Sprint Backlog. Made up of the Sprint Goal (why), the Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). The guide describes it as a highly visible, real-time picture of the work the Developers plan to do during the Sprint, updated throughout the Sprint as more is learned.
• Increment. A concrete stepping stone towards the Product Goal, additive to all earlier Increments and usable. Work cannot be part of an Increment unless it meets the Definition of Done, and an item that does not meet it returns to the Product Backlog.

Product backlog vs sprint backlog, side by side

• Who is accountable. Product Backlog: the Product Owner, who develops the Product Goal, creates and orders the items and keeps the list understood, and may delegate the work but stays accountable. Sprint Backlog: the Developers, whose plan it is.
• What it holds. Product Backlog: every item the product might need, detailed near the top and rough further down. Sprint Backlog: only the Sprint Goal, the items selected for this Sprint, and the Developers’ plan, often broken into work items of a day or less.
• Commitment. Product Backlog: the Product Goal, the long-term objective. Sprint Backlog: the Sprint Goal, the single objective for this Sprint.
• How long it lives. Product Backlog: as long as the product. Sprint Backlog: one Sprint, which is one month or less.
• Who can change it. Product Backlog: the Product Owner orders it; anyone else who wants a change has to convince them. Sprint Backlog: the Developers adapt the plan every day; if the work turns out different from what they expected, they negotiate the scope with the Product Owner without affecting the Sprint Goal.
• Where it is inspected. Product Backlog: at the Sprint Review, where it may be adjusted. Sprint Backlog: at the Daily Scrum, where the Developers inspect progress towards the Sprint Goal.

The Agile Alliance’s entry on the sprint backlog↗ (opens in a new tab) adds two practical points the Scrum Guide leaves to teams: the tasks the team identifies to deliver each selected item become part of the Sprint Backlog, and so do any action items from the previous retrospective. The Scrum Guide says the most impactful improvements from a retrospective may even be added to the next Sprint Backlog.

Change rules: what can move, and when

The Scrum Guide lists four things that hold during a Sprint: no changes are made that would endanger the Sprint Goal; quality does not decrease; the Product Backlog is refined as needed; and scope may be clarified and renegotiated with the Product Owner as more is learned. In practice that gives three rules of thumb.

1. The Product Backlog can change at any time. New items arrive, items are split and reordered, and none of it disturbs the current Sprint.
2. The Sprint Backlog’s plan changes daily; its goal does not. The Developers add, remove and split work as they learn, as long as the Sprint Goal still holds.
3. Scope inside the Sprint is renegotiated, not imposed. An urgent item can come in, but by agreement with the Product Owner and usually in exchange for something of similar size. If the Sprint Goal becomes obsolete, only the Product Owner can cancel the Sprint.

A worked example

A four-person team runs a class-booking app in two-week Sprints. Their Product Goal: members book, move and pay for classes without phoning the studio. Here are both backlogs on day one of Sprint 9.

Product Goal: members book, move and pay for classes
without phoning the studio.

1. Move a booking to another class           (feature)
2. Reminder email uses the wrong time zone   (bug)
3. Pay for a class pack by card              (feature)
4. Waiting list when a class is full         (feature)
5. Show remaining spaces on the timetable    (enhancement)
6. Studio staff can cancel a class and notify members
... 23 more items, less detailed the further down

Sprint Goal: members can move a booking themselves,
and every reminder arrives at the right time.

Selected items: 1, 2 and 5.

Plan (Developers' own, updated daily):
  1. Add the move endpoint; free the old place, hold the new one
  1. "Move" button on upcoming bookings
  1. Send an updated confirmation email
  2. Store class times with their time zone; fix the reminder job
  5. Show "3 places left" on the timetable
  Retro action: add a test for reminder times before merging

On day six a large customer asks for the waiting list, item 4. The Product Owner moves it to the top of the Product Backlog, which is theirs to do. It does not go into the Sprint, because it has nothing to do with the Sprint Goal and would push out item 1. At the Sprint Review the team shows the Increment, moving bookings and correct reminders, and the waiting list is first in line for Sprint 10’s planning.

Common mix-ups

• Treating the Sprint Backlog as a list of items. Without the Sprint Goal and the plan, it is only a slice of the Product Backlog, and nothing tells the team which item to protect when time runs short.
• Letting the Product Owner write the plan. The Scrum Guide gives the how to the Developers: no one else tells them how to turn items into Increments.
• Freezing the Product Backlog during the Sprint. Refinement carries on as needed; only changes that endanger the Sprint Goal are ruled out.
• Keeping two Product Backlogs. A “bugs backlog” beside the product one breaks the rule that there is a single source of work, and the order between the two is never decided.
• Calling unfinished work part of the Increment. Anything that does not meet the Definition of Done goes back to the Product Backlog.

Without sprints

Teams that work in a continuous flow still need a long list and a short one; they just do not reset the short one on a calendar. The Kanban Guide↗ (opens in a new tab) asks members to start work on an item only when there is a clear signal of capacity, so the near-term list is kept small and refilled as items finish, rather than filled once per Sprint. What disappears is the Sprint Goal. Many flow teams replace it with a short written goal for the next few weeks, so they still know which items to protect.

The GOV.UK Service Manual’s page on agile tools and techniques↗ (opens in a new tab) describes the same two lists in plainer terms: a product backlog of stories not yet started, in order of priority, and, if you follow Scrum, a sprint backlog of the stories the team has agreed to work on in that sprint.

Both backlogs on a fenbs board

To be plain: fenbs has no sprints, no Sprint Goal field, no story points and no work-in-progress limits. It has four lanes, To Do, Next Up, In Progress and Completed, and that is enough to hold both lists.

• To Do is the Product Backlog. Priority runs 1 to 10, with 1 the most urgent, and on a team board the Shared order is the exact order everybody sees.
• Next Up is the near-term list: what the team has committed to next. If you run Sprints, it is the Sprint Backlog’s selected items; if you do not, keep it short and refill it as tasks finish.
• Each task’s plan holds the how, rewritten as people learn, which is where the Sprint Backlog’s plan lives when there is no separate task list.
• The goals have no field of their own. Write the Product Goal and the current Sprint Goal into the board’s AI context, which people and every connected AI assistant read.
• A finished task goes to Completed with a test status, so “done but not tested” shows up on the board instead of slipping into the Increment. Items that will not be built are closed as Won’t fix, Duplicate, Cannot reproduce or Obsolete.

If your team relies on sprint reports, burn-down charts or velocity generated by the tool, use a tool built for Scrum. Sprint planning with AI shows how a team runs Sprints on the four lanes anyway.