Creating a DEEP Product Backlog
A product backlog captures the details about all we are planning to do, to achieve our vision. It is a prioritized list of everything that is deemed necessary related to required initiatives, projects and even the smaller things like requests and tech debt.
While the backlog is intended to serve as a simple tool, it can become rather complex to work with in many cases. It becomes an obstacle rather than an enabler for a product manager or product owner to do their best work. The DEEP concept can help to deal with this problem and enhance our chances of building products that customers love.
What is DEEP?
Credited to Roman Pichler and Mike Cohn, DEEP is an acronym for the qualities that a good product roadmap should possess. It provides an easy guide for product managers and product owners to create effective backlogs. DEEP gives us an easy-to-remember aid when putting together product backlogs in Agile / Scrum environments. The acronym denotes: Detailed appropriately, Estimated, Emergent, Prioritized.
What Makes a DEEP Product Backlog?
Let’s examine what each of the four key attributes of a good product backlog entails.
Detailed
This means that items with a higher priority should be best described. These items should be fine-grained and have more details added to them, compared to lower priority items. Items or user stories that are to be worked on soon or in the next sprint should have more contextual information to better guide the team. There is no need for us to make items that we won’t be working on soon to have too many details. This helps to keep our product backlogs from being too long and looking more daunting.
Estimated
We need to also provide a rough estimate for each item or user story in the product backlog. We need to have a ballpark idea of the amount of effort that would be required for each to guide effective prioritization. All items in the backlog must have estimates, although the level of accuracy can vary. Estimates for higher-priority items or items at the top of the backlog need to be more accurate. We can afford to be less precise with lower-priority items because they are assumed not well understood yet.
Emergent
This attribute of an excellent product backlog is especially critical in Agile. We should never see the backlog as something we set and forget. Rather, we need to view it as something that can (and will) change. The product backlog isn’t set in stone. As we progress and get new information, there will be a need to make some alterations or modifications. Items may need to be added, re-prioritized, or removed altogether.
Prioritized
Well, it is probably safe to say that a product backlog isn’t one without prioritization. This is because, by definition, it is a prioritized or ordered list of items to work on. We place high-priority items that promise the most value at the top. On the other hand, we put items with lower values in lower places in the backlog. This makes more obvious what we must do to achieve the best results. It helps us to not lose focus of what matters more to our strategic goals and objectives.
Focusing on the Right Stories
A DEEP product backlog clearly helps us to zero in on user stories that are most important or most valuable. With it, we can be sure that we are prioritizing the right stories. We can sidestep the risk of our backlog becoming a stumbling block rather than a stepping stone. Sometimes, product managers or owners may be handed a pre-prepared product backlog that is probably supposed to make their work easier. But this has the opposite effect. Why? The lists are typically too long and excessively or needlessly detailed.
As Pichler advises, we should summon the courage to tell how lengthy and overly detailed product backlogs can make our work harder rather than easier if presented with one. We may make clearer how such backlogs can hurt our ability to deliver a winning product. It’s best to put aside an excessively detailed product backlog handed down to us and develop a fresh one from the roadmap based on the DEEP principles.
We may not be wrong to say that product professionals create backlogs that are estimated and prioritized in most cases. The criteria that are more likely to not be given enough attention are the first and the third (detailed appropriately and emergent). By trying to make our product backlog DEEP, we can ensure that we do not overlook those attributes as many do.
The Product Backlog is Never Finalized
It is critical to emphasize that a backlog should never be considered as finalized. Our work is not done after creating one. We must ensure that we update it regularly. A DEEP product backlog is an outcome of a grooming or refinement session, a recurrent event that allows the product team to refine details and estimates and to order or re-order items.
A product manager or product owner is responsible for maintaining the product backlog. However, grooming is a collaborative process for the entire product development team. The Scrum team decides what form refinement takes and when it holds, although the product owner may update items at any time.
