Ancient Artifacts: Product Backlog

The canyoneers encounter a very ancient and incorrect definition of a Product Backlog. Is this really what people used to think in this cave (organization)?

15 minutes: In triads or quads, our canyoneers figure out what’s wrong with these statements. Can they rewrite it? (The Scrum Guide may be consulted).

• The Product Backlog is a prioritized requirements document.
• When multiple Scrum Teams work on a single product, they each have their own Team Product Backlog.
• The Product Owner is the sole person managing the Product Backlog, including its content, budget, delivery dates, assignees, and estimations.
• The Product Backlog consists of exhaustive functional and technical instructions.
• The Product Backlog must contain all stakeholder requirements.

Once the 15 minutes are up, let’s see if the canyoneers can find and correct the anti-patterns. Here are some conclusions you might share as a guide once the canyoneers return from their break-out caves.

• The Product Backlog is ‘ordered’, not prioritized. Priority may be an important factor to consider when ordering Product Backlog items. 
• The Product Backlog is not a ‘requirements document’. It contains items *the Scrum Team* believes are needed for the Product and to achieve a Product Goal. 
• Although the Product Owner is accountable for ensuring that the Product Backlog is transparent, the Product Backlog may be managed by the entire Scrum Team. Items in the Product Backlog remain the accountability of the entire Scrum Team and should not be individually assigned. It’s the developers that may size the work needed for an item. Only they can determine if it fits in a Sprint. Establishing delivery dates in a Product Backlog, although possible, may work against empiricism, agility, predictability, and quality. 
• Product Backlog items that can be "Done" by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. By no means does this need to be exhaustive, instructive or fully specified. The Scrum Team may come to this understanding by working its way through the complex problem towards a solution. 
• The Product Backlog, although it is a single source of work undertaken by the Scrum Team, it does *not* need to contain *everything* asked for by stakeholders. A transparent Product Backlog is short and focused on a Product Goal. New needs may emerge into the Product Backlog in a timely matter. 

Follow me