The Product Backlog and the Product Goal: What We Build and Why
The Product Backlog is the ordered, emergent list that is the single source of the Scrum Team's work; its commitment, the Product Goal, says why the list exists. The post shows how ordering weighs value, risk, dependencies and the cost of waiting, why refinement is not an event, and when a Definition of Ready, which is not in the Guide, becomes a gatekeeper, using Bookstore's GitHub Projects backlog.
Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. The sample board is modeled on the table view of GitHub Projects; the same structure works in any tool.
Guess First
Bookstore's backlog has 64 items. The team has put a priority label on each: 38 are P1 (Priority 1, the highest), 19 are P2 (Priority 2) and 7 are P3 (Priority 3). Selin has four candidates in front of her: "Return request screen" (P1, what customers ask for most), "Try the shipping company's return label API (Application Programming Interface)" (P2, nobody has used it before), "Order history page shows the wrong date" (P1 bug) and "Split the 900-line method in OrderService" (P3, technical debt).
Which one should be at the top for the next Sprint? And on a list with 38 P1s, how much information does the "P1" label give Selin? Write down your guess, then let us see why the Guide says "ordered" rather than "prioritized".
The Product Backlog: A Single, Ordered, Growing List
The Guide defines the Product Backlog as an emergent, ordered list of what is needed to improve the product, and the sentence it adds is critical: the Product Backlog is the single source of work undertaken by the Scrum Team. So there is no separate bug tracker, no separate "technical debt list" and no separate "manager's wishes" file; every piece of work the Scrum Team will do is on this list, in this list's order.
The word "emergent" says the list is never finished. On day one, Bookstore's backlog held roughly ten items for the return flow; after the first Sprint Review the support team's request for a "list of return reasons" was added, and in the second Sprint three new items appeared because of the shipping API's constraints. The list grows, changes and sometimes shrinks along with the product.
The word "ordered" has been in the Guide since 2011. The revision notes explain that "ordered" replaced "prioritized" to give the Product Owner flexibility to optimize value in their own circumstances. A priority label is a judgment about a single item; an order is a decision between items. On a list with 38 P1s, the label does not decide anything; it postpones the decision. On an ordered list, two items cannot sit in the same place; one is above the other.
What Determines the Order?
Ordering does not just mean "most valuable on top". At Bookstore, Selin looks at four things together:
- Value: Who benefits, and how much, once the item is done? The return screen promises to save the support team about 120 emails a week.
- Risk and learning: Nobody has used the shipping API; learning the unknowns early makes the work built on top of it cheaper. An experiment that looks low in value can move up because its risk is high.
- Dependency: The return screen assumes a return label can be produced; if the label does not work, the screen is left half done.
- Cost and the cost of waiting: The 900-line method is touched in every return change and slows things down each time. The wrong-date bug produces new customer complaints every day.
The formula versions of these dimensions (RICE, that is Reach, Impact, Confidence, Effort; Cost of Delay; Kano) are in the Introduction to Product Management series post "Prioritization Frameworks: RICE, MoSCoW, Kano and Cost of Delay". Scrum does not require any particular technique here; it only says the decision belongs to the Product Owner and the result is a visible order.
Selin's decision: a two-day spike to try the shipping API at the top, the wrong-date bug right below it (small and costing something every day), then the return screen. The technical debt item was folded into the return screen: since the screen cannot be built without splitting the relevant part of the method, the Developers included that work in the screen's plan. The bug, the spike and the technical debt are on the same list, because they all eat into the team's capacity and stay invisible unless they are ordered.
The Product Goal: Why the List Exists
One of the most important additions in the 2020 version is the Product Goal. The Guide attaches a commitment to each artifact, and the Product Backlog's commitment is the Product Goal. The definition: a future state of the product that serves as a target for the Scrum Team to plan against. The Product Goal lives in the Product Backlog; the rest of the list emerges to define what will fulfill it.
The Guide adds two more rules. The Product Goal is the Scrum Team's long-term objective, and the team must fulfill or consciously abandon one objective before taking on the next. So there are no three Product Goals at once. The second is the definition of "product": a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers. The definition does not limit "product" to a software package; it could be a service or something more abstract.
Let us compare two candidate Product Goals for Bookstore. The first: "Complete the returns module." That is not a goal but the name of a work package; nobody can measure when it is done, and it means whatever the team puts inside the word "module". The second: "Registered customers can start and track the return of a delivered order without writing to support; support emails about returns drop from 120 to under 20 a week." The second describes a future state of the product, can be measured, and makes it possible to ask of every backlog item: "does this bring us closer?" Writing outcome-oriented goals instead of output is covered in detail in the Introduction to Product Management series post "Outcomes over Output: Problem Statements, Hypotheses and Jobs to Be Done".
Refinement Is Not an Event
Product Backlog refinement is the work of breaking items down into smaller, more precise items and defining them further. The Guide defines it as an ongoing activity and does not count it among the five events. Refinement adds details to items such as description, order and size; these attributes vary with the domain of work.
On size, the Guide is clear: the Developers who will do the work are responsible for sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs, but does not set the size. The sizing technique (story points, item counts, T-shirt sizes) belongs to the upcoming Estimation and Planning series; writing good items and acceptance criteria belongs to the upcoming Requirements Analysis series.
The 2017 Guide said refinement usually consumes no more than 10 percent of the Development Team's capacity; the 2020 version removed the number. As a starting point the Bookstore team still holds a 90-minute session in the second week of each Sprint, but most refinement happens during the day: while reading the shipping API's documentation, Ayşe splits the return label item in two and updates the board. The session is a calendar habit; refinement itself is not an event.
Definition of Ready: Helpful or a Gatekeeper?
There is no Definition of Ready in the Guide. The 2013 version introduced the word "Ready" as a state for items that can be Done within one Sprint; the 2020 version keeps the same idea in lowercase: items that can be Done within one Sprint are deemed ready for selection in Sprint Planning, and they usually acquire this transparency after refining activities. It defines no checklist and no commitment.
Many teams still write a Definition of Ready. When it helps: if the team keeps running into the same kind of surprise (for example, items enter the Sprint before an external API's contract is known and get stuck halfway), an item such as "the external dependency's contract is known" is a useful reminder. When it hurts: the list grows into a gate. A list like "design complete, all acceptance criteria written, estimated, test scenarios ready" requires the item's entire analysis to be finished before it enters a Sprint. That turns the Sprint into an implementation phase after analysis, a small waterfall, and the conversation between Developers and the Product Owner within the Sprint is lost. The Guide's statement about the Sprint, that scope may be clarified and renegotiated with the Product Owner as more is learned, asks for exactly the opposite.
Bookstore's rule is short: no Definition of Ready; but if, in Sprint Planning, the question "can we get this Done in this Sprint?" cannot be answered honestly for an item, the item is not selected and goes back to refinement.
The Top Eight Rows of Bookstore's Backlog
In GitHub Projects the team uses a single table view; the row order is set by dragging rows by hand, and a "Type" field shows whether an item is a feature, a bug, a spike or technical debt. This is how it looked before Sprint Planning:
| Order | Item | Type | Why it is here |
|---|---|---|---|
| 1 | Shipping return label API: produce a label with the test account | Spike | The biggest unknown; three items below depend on it |
| 2 | Time zone bug in delivery dates on the order history page | Bug | Small, produces complaints every day |
| 3 | Create a return request for a delivered single-item order | Feature | Shortest path to the Product Goal |
| 4 | Return request is visible in the support panel | Feature | Only this brings the support email metric down |
| 5 | List of return reasons (support team request) | Feature | Came out of the first Review; needed for reporting |
| 6 | Partial return for multi-item orders | Feature | Valuable, but partial refunds at the payment provider are not yet tried |
| 7 | Split the non-return methods in OrderService | Technical debt | Speeds up the next Product Goal; can wait for now |
| 8 | Email notification for return status | Feature | Users can track it in the panel; not urgent |
The "why it is here" column turned out to be the most useful thing for the team. When the reason behind the order is written down and a stakeholder asks in the Sprint Review "why is the email notification so far down?", the discussion moves from people to reasons; that is the "transparent, visible and understood" backlog the Guide asks of the Product Owner.
In Production: What to Watch
Bookstore looks at three numbers to gauge the health of the Product Backlog. First, the length and age of the list: when more than 40 percent of items have not been touched for six months, Selin does a cleanup and closes most of them. A long, stale list reduces transparency; nobody reads 400 rows. Second, the readiness of the top items: how many of the first ten items are small and clear enough to be Done within one Sprint? That number directly determines how long Sprint Planning takes. Third, off-list work: the number of "small" jobs done during the Sprint without ever entering the backlog. If that number rises, the Product Backlog is not the single source of work.
At scale, if several teams work on the same product, the Guide's answer is still a single Product Backlog. Each team keeping its own backlog hides cross-team dependencies and ordering decisions.
Common Pitfalls
Everything being P1. When priority labels replace decisions, the Product Owner's actual job, ordering, does not get done; in Sprint Planning the Developers pick the most familiar or the easiest P1.
Multiple backlogs. Bugs in a separate system, technical debt on a wiki page, the manager's wishes in email. The result: how much of the team's capacity goes where becomes invisible, and Sprint Goals keep breaking under "unexpected" work.
Writing the Product Goal as a feature list or a slogan. "The best bookstore experience in the world" cannot be measured; "Returns module" is a work package. Neither lets you ask whether a backlog item brings you closer to the goal.
Locking refinement into a single meeting and turning the Definition of Ready into a gate. Both turn the Sprint into a line where analysis and implementation are separated.
A Small Experiment
★☆☆ Take the top ten items of your team's backlog and write a one-sentence "why it is here" reason next to each. The number of items you cannot justify shows how much of the order is really a decision.
★★☆ Write a Product Goal for your current product: it should describe a future state of the product and be measurable. Then mark which of the top twenty backlog items do not contribute to that goal.
★★★ For one Sprint, note down the work your team does without it ever entering the backlog (support requests, "can you take a quick look" asks, production fixes). At the end of the Sprint, compare their total time with the time spent on the Sprint Goal, and propose a way to make this work visible in the backlog.
Bookstore's backlog is ordered and has a Product Goal. In the next post we move to the Sprint itself and Sprint Planning: the Guide's three topics (why, what, how), the Sprint Goal commitment and why the word "commit" became "forecast" in 2011.