DEEP Product Backlog

DEEP acronym as an iceberg metaphor

The product backlog in an agile context is the list of deliverables that the team needs to complete in order to deliver value for their customer. Teams starting their agile journey may have challenges forming their backlog ‘just right’. The DEEP acronym provides some advice that helps new teams on their way and acts as a reminder for established agile teams.

Detailed Appropriately

The Product Owner meets with customers and is provided with a set of requirements, needs, wants and desires. The information is recorded and added to the product backlog. The Product Owner in consultation with the team needs to determine how much information to capture for each item in their backlog? 

The advice for the team is to capture enough detail relative to the priority of the Product Backlog Item (PBI) in the backlog. The higher the item is in priority then the more information that will be required as the team will be involved in conversations on how to implement the requirements. For PBIs that are lower in priority then the detail in them will be much less precise.

There are some reasons for keeping PBIs  detailed appropriately:

  1. Capture and Conversation Time – The Product Owner requires time with the business stakeholders and/or customers. They need to take time out of their day to meet with the Product Owner, answer questions, provide details or feedback. Providing high level of detail for all product backlog items may result in the implementation team waiting for the requirements to be fulfilled.
  2. As the team is implementing the PBI, the customer may change their mind as they see the product emerge sprint by sprint. “Requirement Rot” occurs quickly. Spending a large amount of time capturing details in the PBIs that may not be pulled by the implementation team for a few months means possible rework of the requirements, or worse, delivery of a stale requirement that the customer no longer requires, which could lead to significant change costs.

A Suggestion 

Make use of the CCC method – Card, Conversation, Commitment.

People may observe agile practitioners using a lot of small index cards or sticky notes in the same shape. (Software tools for backlog management tend to use digital cards). The concept is to capture enough information as a reminder to have a conversation. The card is added to the Product Backlog as a reminder to have a conversation. As the Product Owner, Team, and customer meet over time to discuss the backlog, they can then make a commitment to implementing the details of the card at the ‘last responsible moment’ in time.


Agile teams primarily work in contexts that are very complex, that is, there is no causality from one event to another. They do not know all of the information they need to successfully deliver a perfect implementation of the requirements. Creative endeavors that lead to a product which you can hold in your hand or load on your computer may have gone through many iterative stages of development and feedback. As the team and customer complete PBI work from the backlog they will learn new things about the problem they are trying to solve. Market conditions may have changed since the team started to produce parts of the product. Legal frameworks update, social norms adjust, technology improves, political landscape changes, among other things. 

The backlog is not a queue of work that the team blindly completes from one item to the next. As the customer in collaboration with the Product Owner make known what used to be unknown, they may decide that a new item needs to be added to the backlog and it fits between work that is already present in the backlog. Items that the customer may have been excited about at the start of the product development may no longer be the amazing ‘secret sauce’ that will lead to billions in sales, thus be moved lower in the backlog to make way for higher value items to percolate to the top.

A Suggestion

Keep options open. For those new to agile practices, ensure that work in the product backlog leads to small advances in functionality for the product or service being developed then present it to the customers. Teams can challenge themselves to build out various options for the customer to consider. This leads to rich feedback from the customer and increased customer engagement. Small advances in the evolution of the product can lead to small change management cycles. Consider a customer that is running a 24 hours a day, 7 days a week operations centre. They will be happy that the changes to their management system requires an hour of mentoring from a team lead vs. shutting down the operations centre for a week to train the staff on a completely revamped module.


Estimation is the process of providing some measure of the effort that it will take to complete the PBI. There are many estimation techniques used in agile disciplines, which will be linked here as those techniques are introduced in subsequent posts. 

Benefits of providing estimates on the PBI work:

  1. To help the team determine the amount of effort required in order to deliver the item. PBIs that are very large and cannot be completed in a specific timeframe may need to be broken down further into smaller units of value. This decomposition of work acts as a risk mitigation technique in agile practices. The smaller the work item is, the sooner the team can get feedback on it from the customer and make adjustments if necessary.
  2. The Product Owner can form a prediction on when a set of PBIs (representing a feature) may be ready for delivery to the customer. Again, this is a risk mitigation strategy that allows the Product Owner and customer to engage in conversation far ahead of any due date commitments. Should the feature set estimation move the prediction far past the due date, then the Product Owner, customer, and implementation team can discuss how to change the scope of the work, and/or bring on additional people into the team to meet any commitments required by the customer.

A Suggestion

Teams should consider estimating work relative to other work they have in their product backlog, given they are solving complex problems and do not have perfect information. Teams working with known unknowns, meaning they only need some expert analysis in order to fully understand the problem then may provide precise time estimates. 

Later, this suggestion will be expanded to include some techniques on how to estimate complex work.


Lastly, the PBIs are prioritized in the backlog. Agile practices work best when teams are performing ‘pull’ based work vs. ‘push’ based work. Push based methods occur when a central authority (like a Project Manager) directly assigns work to team members. Good Project Managers will have developed some mechanism to ensure the team will not be overwhelmed with work, however this is not always the case. Pull based methods occur when the team itself can select the work they can accomplish based on empirical evidence on how they previously delivered the work. 

There are a number of prioritization methods that a Product Owner can select in order to prioritize the work in a backlog, which includes but is not limited to Value Currencies, Weighted Shortest Job First, Cost of Delay, Kano, MoSCoW, and HiPPO (Highest Paid Person’s Opinion).

All PBIs on the product backlog are strictly stack ranked, one above the other. No two PBIs can share the same priority. This provides the clarity that they implementation team requires so they understand what comes next in the backlog. Should the customers and stakeholders change their mind about the prioritization, the Product Owner can hold a prioritization workshop resulting in a rearrangement of the priorities. The updated priorities are communicated to the implementation team in advance of them selecting the work off of the backlog, so they can inspect it and advise if the newly prioritized is detailed appropriately enough.

A Suggestion

Consider 2-3 important aspects of the product or service being developed. Provide a couple sentences on what these aspects mean and give them a title. Use the title as the name of the respective value currencies. When evaluating criteria in the Product Backlog, bring the customers and stakeholders together in a workshop to provide a relative value estimation. Consider giving each person a set of cards with the numbers 100, 200, 300, 500, 800, 1200, 2000, 3000. For each item in the backlog, each member in the group will select in secret a card for each value currency, then reveal those cards all together. The facilitator will select the people whose cards are the furthest apart from each other and ask them to share their thoughts on why they select the value that they did. This process can lead to valuable insights and provides the Product Owner with the information they need in order to properly place the PBIs in a stack ranked order.

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Leave a Reply

Your email address will not be published. Required fields are marked *