06 PRODUCT BACKLOG
The Program Product Owner develops the Program Product Backlog, which contains a prioritized list of high-level business and project requirements, preferably written in the form of major Program Backlog Items or Epics. These are later refined by the Product Owners of individual projects as they create and prioritize Product Backlogs for their projects. These Prioritized Product Backlogs have much smaller but detailed User Stories that can be approved, estimated, and committed by individual Scrum Teams.
The Program Product Backlog is continuously groomed by the Program Product Owner to ensure that new business requirements are added and existing requirements are properly documented and prioritized. This ensures that the most valuable criteria for meeting the program objectives get high priority, while others are put lower on the list.
The Program Product Backlog created for the program presents a larger picture of all projects that are part of the program. Therefore, it can provide significant guidance regarding project goals, scope, objectives, and the expected Business Benefits.
The Scrum Product Owner uses the Scrum Product Backlog during the Sprint Planning Meeting to describe the top entries to the Team. The Scrum Team then determines which items they can complete during the upcoming Sprint.
Each Scrum Product Backlog has certain properties that differentiate it from a simple to-do list:
- An entry in the Scrum Product Backlog always adds value for the Customer
- The entries in the Scrum Product Backlog are prioritized and ordered accordingly
- The level of detail depends on the position of the entry within the Scrum Product Backlog
- All entries are estimated
- The Scrum Product Backlog is a living document
- There are no action-items or low-level Tasks in the Scrum Product Backlog
Figure: Example of Scrum Product Backlog (also see Product Backlog), To Do List. ID, Story, Estimation, Priority. For instance: ID 7: As an unauthorized User I want to create an account, Estimation 3, Priority 1, etc.
The Product Backlog and the business value of each backlog item are the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is determined by the Development Team, who contributes by sizing items, either in Story Points or in estimated hours.
The idea that only User Stories are allowed in a Product Backlog is a common misunderstanding. By contrast, Scrum is neutral on requirement techniques. As stated in Scrum Guidelines:
Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular belief, the Product Backlog does not contain "User Stories"; it simply contains items. Those items can be expressed as User Stories, use cases, or any other set of requirements that the group finds useful. However, whatever the approach, most items should focus on delivering value to Customers.
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner gathers input, takes feedback and is lobbied by many people, but will ultimately have to make the call on what to build. The Product Owner has sole responsibility for management of the Backlog.
The Product Backlog is used to:
- Capture requests for modifying a product. This can include adding new features, replacing old features, removing features and fixing issues
- Ensure the Delivery Team is given work which maximizes the Business Benefit to the owner of the product.
Typically, the Product Owner and the Scrum Team come together and write down everything that needs to be prioritized and this becomes the content of the first Sprint, which is a block of time set aside for focused work on selected items that can be accommodated within a timeframe. The Scrum Product Backlog is permitted to evolve as new information surfaces about the product and its Customers, and so new work is scheduled for subsequent Sprints.
The following items typically comprise a scrum backlog: features, bugs, technical work, and knowledge acquisition. In the web development sphere, there is confusion as to the difference between a feature and a bug, technically a feature is "wanted", while a bug is a feature that is "unintended" or "unwanted" (but not necessarily a fault). An example of technical work would be: "run virus check on all developers' workstations". An example of knowledge acquisition could be a scrum backlog item about researching WordPress plugin libraries and making a selection.
6.2 Product Backlog between Product Owner and Scrum Team
A backlog, in its simplest form, is merely a list of items to be worked on. Having well-established rules about how work is added, removed and ordered helps the whole Team make better decisions about how to change the product.
The Product Owner prioritizes which of the Product Backlog items are most needed. The Team then chooses which items can be completed in the upcoming Sprint. On the Scrum Board, the Team moves items from the Product Backlog to the Sprint Backlog, which is the list of items they will now build. Conceptually, it is ideal for the Team to only select what they think they can accomplish from the top of the list, but it is not unusual to see in practice that Teams are able to take lower priority items from the list along with the top ones selected. This normally happens because there is time left within the Sprint to accommodate more work. Items at the top of the Backlog, the items that are going to be worked on first, should be broken down into Stories that are suitable for the Delivery Team to work on. The further down the Backlog goes, the less refined the items should be. As Schwaber and Beedle put it "The lower the priority, the less detail, until you can barely make out the Backlog item."
As the Team works through the Backlog, one must always be mindful that "changes in the world can happen"; the Team can learn about new market opportunities to take advantage of, competitor threats that arise, and feedback from Customers that can change the way the product was intended to work. All of these new ideas tend to trigger the Team to adapt the Backlog to incorporate new knowledge. This is part of the fundamental mindset of an Agile Team. The world changes, the Backlog is never finished.