All You Need To Know To Build A DEEP And Productive Product Backlog

A product backlog (or backlog) is a prioritized list of features, enhancements, and bug fixes that need to be developed in order to create a successful product. But how to create (and maintain) an efficient backlog? Let me introduce you to DEEP.

Think about a digital product where things need to be developed in a specific order to achieve the product vision: this is the product backlog (aka backlog).

The product backlog is a scrum artifact that consists of a dynamic document that is constantly updated based on feedback from stakeholders, changes in the market, and new insights gained during the development process. It is owned by the product owner and used by the development team to plan their work during each sprint and deliver value to the customer.

To ensure that the backlog is efficient and complete, it needs to be DEEP: Detailed, Emergent, Estimated, and Prioritized. For some teams, the product backlog refinement ceremony can help (it is optional).

By following these methodologies, it is possible to create an efficient and complete backlog with clear stories and well-defined tasks. This helps the development team work more efficiently and deliver a quality product to users.

DEEP Backlog

A product backlog (or backlog) is a prioritized list of features, enhancements, and bug fixes that need to be developed in order to create a successful product. It is a dynamic document that is constantly updated based on feedback from stakeholders, changes in the market, and new insights gained during the development process.

There are some techniques to create a successful product backlog, and one of those is the DEEP Backlog. “DEEP” is an acronym for a set of characteristics that a product backlog should have to achieve a backlog that defines exactly the customer needs: Detailed, Emergent, Estimated, and Prioritized.

According to Roman Pichler, co-creator of the DEEP backlog approach, “to ensure that the product backlog is DEEP and stays that way, you have to groom or refine it regularly. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team.”

Now, let’s understand each letter of the acronym.

D – Detailed appropriately

This means that the product backlog should have sufficient details to ensure clarity for execution but not overly detailed to save waste. Items that will be done in the upcoming sprints (more urgent) should be better detailed, while items scheduled for several sprints later can have fewer details.

One technique to reach this level of detail is the 20/30/50 Rule, introduced by Bob Galen in his book “Scrum Product Ownership”. According to this rule, the items in the product backlog should be divided into three categories:

20% high-priority items: the most critical, detailed, and valuable user stories, which will be started in the upcoming sprint.
30% medium-priority items: the moderately critical, clear, and well-understood user stories, but not as detailed as the high-priority user stories, upcoming in a few sprints (4-10 sprints).
50% low-priority items: User stories that are not ready for work or discussion yet, the product owner should regularly review them and decide if they still fit the future product plans. Upcoming in future sprints (10+).

E – Estimated

When an item in the backlog is estimated, it means that the development team has provided an approximation of the amount of effort or work required to complete that item. The purpose of effort estimation is to provide a relative understanding of the complexity and size of each item in the backlog.

The effort estimation can be in various units. At this point, it is worth mentioning the most common ones: story points, hours, and T-shirt sizing.

Story points

Story points provide a method for determining the level of effort required to complete a task listed in your project backlog. Typically, these estimates are determined in advance of a sprint planning meeting, during which your team allocates work for an upcoming period. These story points consider three critical factors that influence the task’s complexity and effort, with the assigned point value increasing in response to greater challenges:

Risk: the cumulative level of uncertainty linked to a task. For instance, if the task entails third-party involvement, contractors, or engagement with project stakeholders, it may elevate the overall level of risk;
Repetition: the team’s experience with similar tasks;
Complexity: the task’s level of difficulty.
When estimating in Agile, teams typically use the Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) to determine the level of effort. A tip to understand better what each number means for your team is to create a Story Points Matrix which can be evolved according to the experience gained by the team, for example:

T-shirt sizing

T-shirt sizing is a method for estimating and planning the capacity of a project, allowing you to gauge the anticipated time or effort required for an initiative. In this approach, each project or task is assigned a t-shirt size, ranging from Extra Small to XXL, to symbolize the task’s relative effort. Depending on your specific use, this sizing can indicate various aspects, such as task scope, effort, complexity, work hours, time estimates, or a combination of these factors.

Here’s how t-shirt sizing works:

Sizes: Instead of assigning specific numerical values (like story points in the Fibonacci sequence), team members use t-shirt sizes, such as Small, Medium, Large, or Extra-Large, to indicate the relative size or effort of an item. These sizes are generally chosen to be easy to understand and remember.
Comparison: Team members discuss and compare the item they are estimating to other known items in the backlog. For example, they might say, “This new feature is larger than the ‘Medium’ but smaller than the ‘Extra-Large’ feature we completed last time.”
Consensus: Through discussion, the team reaches a consensus on the appropriate t-shirt size for the item. This can lead to better understanding and alignment within the team.
Of course, sizing is different for each team, but one way to define it is:

E– Emergent

The Product Backlog is dynamic and undergoes continuous changes. As the project advances, it gathers increasing amounts of information and insights, resulting in user stories being added, removed, or reorganized within the Product Backlog. This means that the product backlog is not static and evolves as the Product Owner learns more about the product and receives feedback from the market about their releases, such as their Minimum Viable Product (MVP).

The goal of the evolution of the backlog is to keep it aligned and on track with the product plan, that is why the product backlog must have the capacity to be often updated, in a way that it is possible to include relevant User Stories and remove those which are not aligned with the goal anymore.

P – Priorizated

To have an effective and efficient product backlog, it is important to prioritize it in a way that the most necessary and urgent items will be stated at the top (high-value for the business), while the less urgent ones will be allocated below (lower-value for the business). This means that the order of the items in the backlog matters since they will be developed in this order. A clear arrangement highlights our path to achieving optimal results and ensures our focus remains on what aligns best with our strategic goals and objectives.

There are various techniques to prioritize a product backlog, such as Stack Ranking, Kano Model, MoSCoW Method, and Cost of Delay. All of them are useful for prioritizing the backlog, but I especially think I should highlight the MoSCoW method as its usage is increasing.

MoSCoW

The MoSCoW method, originally formulated by the pioneering data scientist Dai Clegg, has its origins in the domain of Agile software development. The MoSCoW acronym is a technique used in project management to prioritize the items in the backlog according to the criticality of each of them. This acronym stands for four priority categories:

Must-Have: Items classified as “Must-Have” are essential and critical requirements or features necessary for the project’s success. They are absolutely required and cannot be omitted.
Should-Have: “Should-Have” items are important but not vital. They significantly contribute to the project, but delaying or deferring these items would not immediately prejudice the project’s success.
Could-Have: “Could-Have” items are desirable but not essential. They are seen as nice additions to the project, but they can be postponed or excluded if there are time or resource constraints.
Won’t-Have: “Won’t-Have” items are requirements or features that will not be included in the current version of the project. They may be considered for future iterations but are not part of the immediate scope.
The MoSCoW method is a valuable tool for project teams to prioritize work and align expectations with stakeholders. It helps avoid the inclusion of unnecessary requirements and focuses efforts on the most critical areas for project success.