A backlog must be DEEP

I am continuing my series of articles about the basics of healthy product ownership. The most fundamental thing in Agile is the product backlog. Borrowing from Dave Todaro and his book “The Epic Guide to Agile,” I said that the basic building blocks of a product backlog are user stories, bugs, and tasks. Today, I want to emphasize the structure of a backlog. 

Roman Pichler writes plenty of great books about Agile. My favorite is “Agile Project Management with Scrum.” Here, Pichler outlines his DEEP model of product backlog management. For a backlog to be robust, it must have the following necessary and sufficient conditions:

• It must be Detailed.
• It must be Estimated.
• It must be Emergent.
• It must be Prioritized.

I have blogged about each of these conditions in other blog posts. Today, I want to review them again and develop some structure you can use to ensure that your backlog is healthy and helping drive value. 

Many businesses actively view a product backlog as a grocery list to fill. It is a mindset geared toward failure. Even the most successful software projects began as small experiments that grew and adapted to market conditions. So, unfinished items are revised based on what the customers want. That is why we say a backlog is emergent and prioritized. A business must determine what is important and do those things first, and if the market determines those priorities need to shift, we must be flexible and intelligent enough to change them. Ego is the enemy of agility. 

One of the most universal features of project management is that once you start doing the work, there is no way to know how long it will take to complete the task. The reality is known as the cone of uncertainty. Estimates can be wildly off by a factor of eight from the low end to the high side of the budget and timeline. The only way to reduce the uncertainty is to do the work, which means that you are adding more detail and information to user stories. It also means that estimates may change as more information becomes available. The code of uncertainty will narrow, but it will take time and patience, which are in short supply in the global economy.

The properties of detail, estimation, emergence, and prioritization combine to make your backlog resemble a leaderboard at the golf event. A golfer rises and falls on the board based on the condition of the course. Halfway through a tournament, a cut takes half of the golfers out of contentions—the ones who make “the cut” then compete for the real money and recognition. Instead of golfers moving up and down a leaderboard, think of the user stories moving up and down the backlog based on the competitive information from your customer base. 

The road to healthy product ownership travels through a detailed, estimated, emergent, and prioritized backlog. A product backlog that meets those conditions will deliver value to the project and generate revenue for the firm, which keeps everyone working for another day. 

Until next time.