James O. Coplien

Well, guess what: the Product Backlog is not how Scrum communicates needs to the team; it is neither priority-ordered nor built around requirements. Yet many Scrum teams carry over practices and artifacts from the waterfall world and fail to realize all that the Scrum way has to offer.

Perhaps the best way of thinking of the Product Backlog is as a register for all decisions made between the Product Owner, Developers, and stakeholders. So, first, it is not so much a communication tool as a tool to remember decisions. People write for two reasons: to communicate and to remember. To a first approximation, we don’t use writing as our primary communication mechanism in Agile. We speak person to person. We do write to remember.

Second, it’s a Product Backlog, not a requirements backlog. It is divided into Product Increments that are cogent units of delivery that appear at the end of each Sprint cycle. The backlog is further broken down into Product Backlog Items (PBIs), which are independent units of delivery sized to reduce risk by increasing the frequency of feedback and by reducing leakage. They are usually not the advertised features of delivery but should be thought of as internal divisions of work to reduce risk and mark progress. The focus isn’t on delivering a percentage of the PBIs but on delivering the Sprint Goal. The Product Increment should always deliver a coherent function, which is most often tied to the Sprint Goal. Correspondingly, there are no user stories on the Product Backlog! (Think about it.)

Each of these Product Backlog slices represents some aspect of a deliverable that the Product Owner has envisioned. They represent solutions to be built rather than requirements to be addressed. Yes: we can annotate PBIs with requirements, but the Product Owner who relates only requirements is shirking their responsibility to own the product—not just its requirements. Hence, the catchy title.

Third, the Product Backlog is ordered by delivery—not priority. Mismanaged dependencies are the bane of complex development. By designing the delivery plan around delivery order, the team can easily plan to reduce dependency surprises up front. Further, customers know the order in which they will get things (unless feedback causes everyone to agree to change things), and, in the best developments, know about when they will be getting them. This supports flow through the process at a macro level. Product Owners may of course keep a list of either requirements or Product Increments ordered by priority. It’s just that that list is not the Product Backlog.

This has profound repercussions for the process. In old-style development, the Product Manager would clarify requirements to the Developers, who would design a business solution and create a technical implementation of that solution. In Scrum, Product Owners take business requirements and shape a business solution that follows their Vision and communicate it to the Developers, who in turn craft an implementation using tools and technologies of their choice.

So, when you think “Product Owner,” think Steve Jobs for the iPhone, or Linus Torvalds for Linux, or Lee Iacocca for the Mustang. It’s that person with the Vision—the Vision of the product.