Here is a quick overview you need to understand 4 things to know about backlog management.
Thing 1: What is a Backlog and how do you define a backlog?
A project backlog is a prioritized and structured list of deliverables that are a part of the scope of a project. It is often a complete list that breaks down work that needs to be completed.
Agile methodology focuses on products. Still, project-based organizations are still applying some Agile practices, such as working with backlogs. The project backlog replaces the product backlog. The main difference is that the project backlog is temporary. It will live as long as the single project. Whereas a product backlog (in theory) will have no end date and be used continuously throughout the lifecycle of a product.
Thing 2: How do you maintain a backlog?
The product backlog contains product features (descriptions of desired functionality in the form of user stories), possible bugs and challenging issues, technical work items (insightful research), and knowledge acquisition (upgrades of workstations).
A proper backlog is dynamic, constantly improved upon, and is never really “complete.”
The prioritization of backlog items are defined by their business value. The higher priority an item is, the sooner a developer team will work on it. Typically, these tasks have more detailed explanations associated with them, unlike lower priority items. It’s crucial to make these clear and easy-to-understand for non-technical stakeholders.
Thing 3: What is a Product Backlog Example?
Product Backlog by goal Example
There are many ways to structure a backlog. Goal driven backlogs aim to capture the goals and vision of the product broken down to sub-features.
Here’s what can happen when product backlogs are structured around goals:
Teams can stay focused on business value. The benefit with this structure is that it all but guarantees that teams are:
- Focusing on items with high business value.
- Improving the right things in the product.
Work can be more measurable and accountable. By defining these high-level goals (also called “business epics”), we can create quick, measurable feedback loops to understand whether we are working on the right thing or not. Also, we become held accountable for meeting our goals, which we see every day in the backlog.
All product backlog items are estimated by developers. Their estimations determine the number of items that will be selected for the upcoming sprint.
Proper Backlog Management of your Product Backlog is crucial. Quality Backlog Management results in a backlog that is dynamic, constantly improved upon, and is never really “complete.” In highly-competitive conditions, it is important to concentrate on the highest priorities, especially when product ideas and tasks begin to “snowball.” The prioritization of backlog items are defined by their business value. The higher priority an item is, the sooner a developer team will work on it. Typically, these tasks have more detailed explanations associated with them, unlike lower priority items.
Here is an example of a scrum backlog
Thing 4: What is a good product backlog?
Good product backlogs share similar characteristics, which Mike Cohn and Roman Pichler captured with the acronym DEEP: Detailed appropriately, Emergent, Estimated, Prioritized. Let’s look more closely at each of these characteristics.
Detailed Appropriately
The product backlog items will differ in their level of detail. Those that we will work on sooner, those at the top off the product backlog, will be more detailed. Those that we won’t work on for some time will be less detailed. We want to refine (add detail to) backlog items as they rise in priority, adding details in a just-enough, just-in-time fashion.
Emergent
As discussed in earlier chapters, the product backlog is a living document, constantly changing as the product is being developed or maintained. As the team and product owner learn more about the product and the marketplace, they might add new items, discard some, and change others. The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog.
Estimated
At the appropriate time, each product backlog should have a size estimate that corresponds to the effort required to develop that item. The product owner uses these estimates to help determine a product backlog item’s priority. Ideally most of items at the top of the product backlog will be sprint-sized, small enough to be worked on during a single sprint. Large, high-priority items should be broken into smaller stories prior to being declared sprint-ready (see Definition of Ready for more on this concept).
Prioritized
A product backlog should be a prioritized list of PBIs, but not every PBI needs to be prioritized. I recommend prioritizing about a release worth of PBIs. Prioritizing beyond that is likely a waste of effort, as too much might change by the time the first release is out. Instead, prioritize new items as they emerge and save the “someday” or “future release” items for later.
GROOMING
To create a DEEP product backlog, we must take the time to groom the product backlog. Let’s look briefly at what that entails. Grooming is made up of three principal activities: creating and refining PBIs, estimating PBIs, and prioritizing PBIs. These activities take place throughout the product development effort.
Good product backlogs share similar characteristics, which Mike Cohn and Roman Pichler captured with the acronym DEEP: Detailed appropriately, Emergent, Estimated, Prioritized. Let’s look more closely at each of these characteristics.
Detailed Appropriately
The product backlog items will differ in their level of detail. Those that we will work on sooner, those at the top off the product backlog, will be more detailed. Those that we won’t work on for some time will be less detailed. We want to refine (add detail to) backlog items as they rise in priority, adding details in a just-enough, just-in-time fashion.
Emergent
As discussed in earlier chapters, the product backlog is a living document, constantly changing as the product is being developed or maintained. As the team and product owner learn more about the product and the marketplace, they might add new items, discard some, and change others. The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog.
Estimated
At the appropriate time, each product backlog should have a size estimate that corresponds to the effort required to develop that item. The product owner uses these estimates to help determine a product backlog item’s priority. Ideally most of items at the top of the product backlog will be sprint-sized, small enough to be worked on during a single sprint. Large, high-priority items should be broken into smaller stories prior to being declared sprint-ready (see Definition of Ready for more on this concept).
Prioritized
A product backlog should be a prioritized list of PBIs, but not every PBI needs to be prioritized. I recommend prioritizing about a release worth of PBIs. Prioritizing beyond that is likely a waste of effort, as too much might change by the time the first release is out. Instead, prioritize new items as they emerge and save the “someday” or “future release” items for later.
GROOMING
To create a DEEP product backlog, we must take the time to groom the product backlog. Let’s look briefly at what that entails. Grooming is made up of three principal activities: creating and refining PBIs, estimating PBIs, and prioritizing PBIs. These activities take place throughout the product development effort.
The end result of grooming should be that the items at the top of the backlog are ready to be moved into a sprint. Some teams formalize this state using a definition of ready checklist for product backlog items. A sample definition of ready is shown in the following table:
a. Business Value is clearly articulated
b. Acceptance Criteria are clearly defined etc.
Good product backlogs also include good release flow management and sprint flow management.
We went through 4 things to know about to make your product backlog look good. What are some things you do to make your product backlog look good?
