The Product Backlog and the Product Goal

One objective at a time

The Product Goal is the long-term objective for the Scrum Team and it lives in the Product Backlog. It describes a future state of the product that the team can plan against, and the rest of the backlog emerges to define what will fulfil it. Scrum is strict about the count, in words worth having exactly: the team "must fulfill (or abandon) one objective before taking on the next".

So a team with three Product Goals pinned to the wall, one per market segment, and Sprint Goals that alternate between them has three directions rather than one. Ordering the three against each other does not repair it — that only decides which of three directions gets attention this fortnight, and the artifact exists to be a single target everything else is planned against. Keep the two goals apart while reading a question: every Sprint has its own Sprint Goal, and the Sprint Goals are the steps toward the one Product Goal.

The single source of the work

The Product Backlog is an emergent, ordered list of what is needed to improve the product, and Scrum states its role in one clause: "It is the single source of work undertaken by the Scrum Team." That is what makes a second list a transparency problem rather than an untidiness.

The version the exam describes is a private list of technical debt and infrastructure work in a separate tool, pulled from whenever there is spare capacity so that it never has to compete with features — often with the Product Owner's knowledge and blessing, which is what makes the scenario feel harmless. It is not. Everyone downstream is reasoning about a product whose real workload is larger than the artifact says: the ordering is a partial picture, so is anything forecast from it, and so is what stakeholders are shown at the Sprint Review.

The objection behind the arrangement is real — technical work does tend to lose to features when both are on one list. Scrum answers it by making the trade-off visible to the person accountable for it rather than by hiding the work from them, and the fix is to put the work in the Product Backlog, never to stop doing it.

Order and size come from different people on purpose

Ordering Product Backlog items is one of the Product Owner's four accountabilities. Sizing is not: the Developers who will be doing the work are responsible for it, and the Product Owner's lever is persuasion — helping them understand and select trade-offs, which in practice means make it smaller, drop that part, accept this constraint.

The separation is what keeps the conversation honest, because value and cost are then judged by different people and a proposal has to survive both. A Product Owner who arrives at refinement with sizes already written against the top ten items, carried over from a similar product last year, has supplied both numbers, and the tension the two accountabilities exist to create has quietly gone. Outside experience is useful input and the Developers are free to seek it; the accountability stays with the people who will build this thing, in this team, on this codebase.

Refinement is an activity, not an event

Refinement is breaking items down into smaller, more precise ones and adding detail such as a description, order and size, and which attributes matter varies with the domain of work. It is ongoing: the Scrum Team may refine during Sprint Planning, and the Product Backlog is also refined as needed during the Sprint. Scrum defines five events and this is not one of them, so it has no timebox to publish and no attendee list to mandate — a team that chooses to hold a regular session is following its own practice rather than a rule of the framework.

Two wrong answers are worth recognising on sight. Calling refinement the sixth event and giving it ten per cent of the Sprint quotes a figure from an older edition of the Scrum Guide that the current framework does not contain. Calling it the Product Owner's private preparation ignores that sizing belongs to the Developers and that items usually acquire enough transparency to be selected precisely by being refined together.

What refinement aims at has a name the exam uses carefully: items that the Scrum Team can Done within one Sprint are deemed ready for selection at Sprint Planning. Ready is about size and clarity, Scrum names no separate Definition of Ready to satisfy, and how a team gets an item into that state is entirely its own business.

What the Product Owner is accountable for

Four things, and every one of them is about the Product Backlog: developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering them, and ensuring that the Product Backlog is transparent, visible and understood. The qualifiers are not decoration — a Product Goal nobody can repeat back has not been explicitly communicated, and a backlog living in a tool nobody opens is neither visible nor understood, which means the inspection that depends on it cannot happen.

The reliable test for any Product Owner question is whether it concerns what the product should be or how it will be built. Selecting which items go into the Sprint is the Developers' through discussion with the Product Owner; planning how the work becomes an Increment is at the Developers' sole discretion; setting the Definition of Done belongs to the Scrum Team where the organisation has not set one. None of those is on the list above, and each turns up as an option.