314days until
ScrumPLoP!

Product Backlog

... you have defined a 
Value Stream by which the Product Owner's Vision flows to the market. You envision a business organization in the enterprise, supported by one or more Development Teams that need strategic direction. Many stakeholders, including Team members, have different ideas on how to achieve the Vision. The Development Teami needs guidance on how to interact with the Product Owner to support the best implementation of the Vision.


✥    ✥    ✥


At any given time, it is important that everyone agrees to what needs to be delivered next, and that the agreement be made transparent. The Team can't do everything at once — in fact, you can't even do two things well at the same time. It's important to have focus.

It's important to make decisions about the product direction transparent to stakeholders.The delivery order must reflect dependencies between deliverables, as well as coordination with project calendar events: deliveries from suppliers, market campaigns, releases by partners or competitors, and so forth. Each Development Teami needs its own direction, yet coordination becomes difficult if each team maintains its own list of product increments. But keeping a separate list for each of these makes it impossible to easily see the order of delivery.



Even a single company may have multiple enterprises. In AT&T we had one part of the company that would sell Private Branch Exchanges — telephone systems that we would sell to companies to support their internal telephone (and data) traffic. Another part the company provided the same service through a company's connection to AT&T's central switching office. Without good planning of their respective directions, these two divisons could unwittingly compete with each other in destructive ways.

Therefore: Create a single ordered list of product increments called Product Backlog Items (PBIs), arranged in delivery order. The list is called a Product Backlog. It details the Product Owner's vision for the product with each PBI describing a deliverable product increment. The Product Owner has final authority over the content of the Product Backlog; however, he or she 
usually develops the 
Product Backlog
 with intimate input from the 
Development Team
 during 
The Backlog Refinement Meeting
 and the 
Sprint Planning Meeting
, and steers the vision with input from all stakeholders. A refined backlog is said to be "
Ready
." 
 Development Teams are driven by the work at the top of the Product Backlog, and each Development Team works from only a single Product Backlog. All Development Team work is driven by PBIs — developers respond to no other source of work requests



✥    ✥    ✥


The
Product Backlog
 makes the current likely trajectory of long-term delivery transparent to all stakeholders. It is typically derived from or inspired by a Product Vision 
 or some other strategic document that captures value drivers.
 This list typically corresponds to a single product or product line; however, it can be any list of deliverables over which a single Product Owner has authority. We give the Product Owner  authority over the 
Product Backlog
 because he or she is accountable for value (ROI), and the 
Product Backlog
 is the sole instrument reflecting the Product Owner's control over the Development Team's sprint towards value.
The Product Backlog
 details the 
Product Owner
vision to drive the remainder of the 
Value Stream.

The 
Product Backlog
 provides an opportunity for feedback from stakeholders early in the lifetime of a product increment in the 
Value Stream. It is visible to all stakeholders including end users, partners, Team members, and any management roles that may exist in the organization
. It is dynamic and can change when
ever the 
Product Owner
  gains new information about the market, business conditions, new estimates from the 
Development Team, or anything else that may affect the Vision or 
 
ROI. At any given time it represents the Product Owner's  best possible realization of  the Vision.

Having a single 
Product Backlog
per product can put an end to the thrashing that can occur between undirected divisions within a company.

The 
Product Backlog
 is typically used to represent requirements and to record the joint decisions made by Scrum Team members, rather than to communicate requirements from one party to another. The Product Owner discusses requirements face-to-face with the Development Team 
during 
The Backlog Refinement Meeting
 and the 
Sprint Planning Meeting to bring them to a vision of an Enabling Specifications. The 
Product Backlog
 may contain more or less information about dependencies between PBIs, market timing constraints, or any other structuring of the requirements. Annotating each PBI with a cost or estimate of effort, as well as that PBI's contribution to ROI, can help the Product Owner optimize ROI during business planning. Any PBI's contribution to ROI of course needs to be adjusted as its position changes in the backlog, since an earlier or later delivery will change the PBI's alignment to market need. As the Development Team estimates PBIs the Team can derive a rough Release Plan. The Product Backlog is usually demarcated with Sprints, which are the units of granularity of the product delivery schedule.

Break down the topmost PBIs according to a Granularity Gradient and refine them to be Enabling Specifications. Periodically ensure that the team has a Refined Backlog.

Historically, Jeff Sutherland split Toyota's Chief Engineer into the Product Owner and ScrumMaster roles, reflecting business and development concerns respectively. The 
Product Backlog
is the main Scrum artefact for the business half of that split while the Sprint Backlog reflects the development part.

The 
Product Backlog
 makes Work Flows Inward possible.