Backlogs
There are a number of backlogs represented in the agile process that all represent work required to enhance a product, but have slightly different context. The backlogs represented in this document include the Product Backlog, Release Backlog, Operational Backlog and Sprint Backlog.
Product Backlog
The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks. Typically, a Product Owner writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
The product backlog items are best represented as User Stories to represent the role, requested activity and business value (See Agile Guideline – User Stories). Items in the Product Backlog may be any size, and will change over time as the team develops aspects of the product and the Product Owner gains feedback from customers and other stakeholders.
The Product Owner is responsible for prioritizing the items in the Product Backlog and describing them to the team. The team is responsible for estimating the size of the items in the Product Backlog and posing questions to the Product Owner for clarification. Both the Product Owner and the team are responsible for breaking down the items in the Product Backlog if they are too large to estimate.
Release Backlog
A Release Backlog is simply a limited set of items from the Product Backlog selected for a specific release. While the product backlog may contain all of the wish list for the product without regard of timeframe, the release backlog is focused to specific objectives or goals identified for a specific timeframe and identified in the Release Data Sheet.
Items in the Release Backlog should be estimated in story points. Estimating the items in the release backlog, along with the creation of the Release Burn Down Chart, will allow the team to visualize the release goal, use actual sprint velocity to track their progress and determine their ability to reach their goal, provide release feedback to the team on their estimates, and help make scoping decisions.
The Release Backlog should be created for a relatively short time period. Three months is a reasonable time frame and allows for about 5 or 6 two-week sprints.
Operational Backlog
The Operational Backlog, or Parking Lot, is the appropriate location to represent work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code refactoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc...
While these items could be located in the Product Backlog, they typically are not directly exposed to the stakeholders during sprint reviews and are not required to be calculated in the Release Burn Down Chart. Often times Product Owners have difficulty having these items in their Product Backlog because they have little understanding of them. However, it is important that the items in the Operational Backlog be balanced and prioritized with the items in the Product Backlog during the release. Often this balance in prioritization requires discussion between the Product Owner and an architect representing the team. Too much focus on either backlog will negatively impact the other. If the Operational Backlog items are ignored, the technical debt will increase and the product architecture will become fragile increasing future development efforts. Too much focus on the Operational Backlog may be interpreted as over-engineering a solution and the team will miss out in early visibility and feedback of new features.
Sprint Backlog
The Sprint Backlog is different from all of the other Backlogs described above. Unlike the Product, Release or Operational Backlogs, the Sprint Backlog contains tasks to be accomplished within a specific sprint for each item in the Product Backlog taken in the sprint.
The Sprint Backlog is typically represented by the Sprint Task Board and is created during the Sprint Planning Meeting. The team owns the Sprint Backlog and can make any changes to it during the sprint including creating new tasks, removing tasks, re-estimating remaining work on tasks and changing their state as they take and work on the tasks.
During the sprint, the team should discuss items in the Sprint Backlog (tasks on the Sprint Task Board) with respect to dependencies between the items, progress toward their completeness, and other issues or impediments to completing them during the sprint. This should certainly be done at the Daily Scrum Meeting, but should also occur naturally throughout each sprint day.
Product Backlog
The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks. Typically, a Product Owner writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
The product backlog items are best represented as User Stories to represent the role, requested activity and business value (See Agile Guideline – User Stories). Items in the Product Backlog may be any size, and will change over time as the team develops aspects of the product and the Product Owner gains feedback from customers and other stakeholders.
The Product Owner is responsible for prioritizing the items in the Product Backlog and describing them to the team. The team is responsible for estimating the size of the items in the Product Backlog and posing questions to the Product Owner for clarification. Both the Product Owner and the team are responsible for breaking down the items in the Product Backlog if they are too large to estimate.
Release Backlog
A Release Backlog is simply a limited set of items from the Product Backlog selected for a specific release. While the product backlog may contain all of the wish list for the product without regard of timeframe, the release backlog is focused to specific objectives or goals identified for a specific timeframe and identified in the Release Data Sheet.
Items in the Release Backlog should be estimated in story points. Estimating the items in the release backlog, along with the creation of the Release Burn Down Chart, will allow the team to visualize the release goal, use actual sprint velocity to track their progress and determine their ability to reach their goal, provide release feedback to the team on their estimates, and help make scoping decisions.
The Release Backlog should be created for a relatively short time period. Three months is a reasonable time frame and allows for about 5 or 6 two-week sprints.
Operational Backlog
The Operational Backlog, or Parking Lot, is the appropriate location to represent work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code refactoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc...
While these items could be located in the Product Backlog, they typically are not directly exposed to the stakeholders during sprint reviews and are not required to be calculated in the Release Burn Down Chart. Often times Product Owners have difficulty having these items in their Product Backlog because they have little understanding of them. However, it is important that the items in the Operational Backlog be balanced and prioritized with the items in the Product Backlog during the release. Often this balance in prioritization requires discussion between the Product Owner and an architect representing the team. Too much focus on either backlog will negatively impact the other. If the Operational Backlog items are ignored, the technical debt will increase and the product architecture will become fragile increasing future development efforts. Too much focus on the Operational Backlog may be interpreted as over-engineering a solution and the team will miss out in early visibility and feedback of new features.
Sprint Backlog
The Sprint Backlog is different from all of the other Backlogs described above. Unlike the Product, Release or Operational Backlogs, the Sprint Backlog contains tasks to be accomplished within a specific sprint for each item in the Product Backlog taken in the sprint.
The Sprint Backlog is typically represented by the Sprint Task Board and is created during the Sprint Planning Meeting. The team owns the Sprint Backlog and can make any changes to it during the sprint including creating new tasks, removing tasks, re-estimating remaining work on tasks and changing their state as they take and work on the tasks.
During the sprint, the team should discuss items in the Sprint Backlog (tasks on the Sprint Task Board) with respect to dependencies between the items, progress toward their completeness, and other issues or impediments to completing them during the sprint. This should certainly be done at the Daily Scrum Meeting, but should also occur naturally throughout each sprint day.
