A product backlog is a prioritized list of items that the team plans to work on to achieve a particular outcome. It is a list of everything that the development team will work on to achieve a strategic objective of a product.
Typical items that you can find in this document include new requirements for new features, changes to old features, bug fixes, and technical work (tech debt, etc). In Scrum, features are usually presented as user stories that describe required functionality from the user’s perspective.
The product backlog is an important tool for product management. Product managers are chiefly responsible for maintaining it and ensuring that it is well-prioritized.
Backlogs usually pass through grooming or refinement sessions to ensure they contain the right items, and in the best order. A well-groomed backlog helps the team to focus on the right stories and features. It assists in estimating planned features.
The DEEP Product Backlog
Certain qualities are important for backlogs that work. Roman Pichler and Mike Cohn capture these in the acronym, DEEP. The vital attributes thus summed up are:
Detailed appropriately – The requirement here is that items should be accompanied by information that enables everyone on the cross-functional team to get the true picture. User stories should be easy to understand, with adequate information provided, especially when scheduling for near-term sprints.
Estimated – The product backlog is a planning tool, so it helps if it gives an idea of the work required. Items should have rough estimates of efforts they require to complete. High-priority items at the top of your list need to be more accurate than those down the list.
Emergent – You should not see the backlog as something you set and then forget. With new learning, you will have to ring the necessary changes – add, remove, or re-order.
Prioritized – This is a pretty obvious quality of a backlog. Arranging items in the right order is what makes them useful since you can’t always execute everything. You prioritize items to ensure the team is always doing more valuable work.
There is a temptation for some product managers to give less attention to the first and third attributes, Pichler observed. You need to guard against that.
Product Backlog Prioritization Techniques
A groomed backlog is a prerequisite for sprint planning. A product manager is expected to turn up at such a session armed with a properly detailed and prioritized product backlog.
There are several tools you can use to determine what is more important to work on. We briefly describe a few of them below.
ICE Scoring Method
ICE Scoring is named for an acronym that outlines a scoring rubric: Impact, Confidence, and Ease. The method, which is credited to Sean Ellis, simply prioritizes backlog items based on those factors. It factors in the expected impact of a feature, the level of confidence in your hypothesis, and the ease of building the feature.
The formula for arriving at a score is:
Impact x Confidence x Ease = ICE score of feature
The final scores of features will be used for prioritization.
MoSCoW Method
MoSCoW describes four factors that can help for prioritizing your backlog: Must have, Should have, Could have, and Won’t have. As you can see, it simply provides you categories that you can split items in to guide your work effectively.
Must have – This refers to features that are critical for your product to have. Without them, the user can consider your product useless.
Should have – These features are important but you don’t have to implement them immediately.
Could have – Some features are not really that important, but users can have a better experience by having them. This type belongs here.
Won’t have – You have here less useful items. It doesn’t mean that you will not work on them but just not at this time.
Kano Model
Named for Japanese professor Noriaki Kano, the idea behind this approach is somewhat similar to that of MoSCoW Prioritization. The framework classifies features based on customers’ needs and expectations.
The criteria for categorizing items using the Kano model often differ slightly. Common categories include:
Must-be – These are features that customers expect your product to include. If your product lacks them, users may deem it outright bad or lousy.
Performance or one-dimensional – By this, reference is to features that make customers more satisfied or happy when present. Their absence leads to greater discontent.
Attractive – Also called “delighters,” these are features that users don’t expect but are excited to have. Users are not displeased if they are missing.
Indifferent – Some features make little or no difference to customers; they go here. These features have practically no effect on customer satisfaction.
Story Mapping
This approach entails arranging user stories in such a manner that they provide a better picture of how they impact the overall user experience.
User stories are organized along two axes. The horizontal, or X, axis shows the sequence of use or the journey of the user through the system. The vertical, or Y, axis represents the criticality or priority of tasks.
Another concept you might also come across when discussing the backlog is the Icebox. This is a list of things that are yet to be prioritized and that you don’t intend working on soon. However, they provide value and, therefore, should be retained.