A DEEP Backlog is a Healthy Backlog

Is your product backlog so overgrown that it’s starting to become a hindrance rather than an advantage? Keep reading to add another acronym to your tool belt and learn how to whip your Product Backlog into shape.

What is DEEP in Product Backlog?

DEEP is an acronym for Detailed appropriately, Estimated, Emergent, and Prioritized.

This mnemonic helps us remember the qualities of a healthy backlog. Once we know what healthy looks like, it’s easier to see where we can improve and advance toward that target.

Detailed Appropriately

Detailing product backlog items occurs on a spectrum. We can pack stories with so much information that no one has the time or desire to read them or supply so few details they’d fit on a fortune cookie strip.

Obviously, these are opposite ends of the spectrum, and we want to be somewhere in the middle. The fact that goes missed by a lot of Product Owners is that the target for the level of specificity changes based on the implementation horizon of the Product Backlog Item.

Iterative and incremental are core concepts in agile approaches. The Product Backlog is no exception to this rule.

In college, I took an English course that required us to write twenty different papers in a single semester. Worried about my chances of success, I started looking into alternative options, and I learned it was a core requirement and unlikely to be easier under another professor. After seriously considering dropping the course, I accepted my fate and decided to make a heroic attempt to pass this class.

Even in college, I was a bit of a productivity addict, knew some tactics for getting stuff done, and recognized my weaknesses. I weighed my choices as I stared at the due dates for the twenty assignments.

I could start with the easier ones and gain some momentum (snowball effect). I could work on all twenty simultaneously, allowing me to switch topics when I lost interest in a subject and continue to progress instead of sluggishly pushing through at the rate of a gameshow contestant swimming through honey. I could have started with the ones I was most passionate about. But, how much passion can a kid have for an English assignment?

Although these approaches each have their benefits, they have one glaring flaw. Working the assignments out of sequence puts the due date at risk.

I quickly realized that the approach that maximized value delivery was writing the papers based on their deadline. Any significant time I spent writing future essays would reduce the time available to finish the first assignment. As my deadlines loom closer, I’m more apt to cut corners and turn in low-quality work.

Toward the end of the semester, my professor dropped the last three assignments from the class requirements as we approached the holiday season. I remember my relief that I had devoted nearly no time to those assignments. It would have been a waste if I’d risked my progress to create a work that the professor would never review.

This same sort of logic applies to the Product Backlog. The items coming up in the near term need to be sufficiently detailed to facilitate a shared understanding and allow work to begin. The items at the bottom of the backlog only need to have enough detail so that future us will remember what we were referring to. If we get to the next user story and no one remembers what it’s for, it probably wasn’t that valuable. It’s not a miss that we didn’t detail it enough; it’s a good thing that the Product Owner spent their efforts on more valuable items.

Estimated

A Product Backlog Item is estimated when the team has assigned it a value that represents its approximate size.

This estimation unit should account for complexity, uncertainty, risk, and effort. There are a lot of generally accepted methods for estimates, such as story points, ideal days, and t-shirt sizes. When selecting an agile estimation technique, the development team should pick one that resonates with them.

Given that an estimate is a guess, it will only be accurate if we get lucky. So we’re not worrying about precision; we need an approximate estimate based on our current understanding of the feature request.

Knowing the general size of a request will help the Product Owners make better decisions regarding trade-offs and prioritization.

Emergent

A Product Backlog is emergent when we accept that items will change over time and develop processes that do not deter the creation, elaboration, or removal of items on the backlog.

I once worked on a project that crossed multiple teams. The individual teams attempted to follow an agile process, but leadership wanted to manage the program using a traditional methodology. Every week we’d review the project plan, and every week we shifted dates.

Eventually, executive leadership started demanding to know when we’d have the plan finalized. The answer is: when we’re done with all the work because we are continuing to learn as we progress.

Traditional project management has given scope creep a bad name. Still, the truth of the matter is that, at any given point, we know the least we’re ever going to about a project because we acquire new information.

New information will likely have an impact on our Product Backlog. Either we’ll want to elaborate on an existing item or create a new one to capture a need that we previously didn’t recognize. In a world where this new request is more valuable than the previous request, why would we want to prevent the team from working on the new valuable request instead of what we used to think was valuable?

I don’t know about you, but I’m glad that I’ve had an opportunity to change the plan I had for myself as I’ve progressed through my life instead of being locked into what 8-year-old me deemed a great path.

The Big Design Up Front approach claims we can predict all outcomes, plan contingencies, and execute perfectly. The agile manifesto has something to say about this topic as well.

”[We value] responding to change over following a plan”

-Agile Manifesto

All of this boils down to: We should update the Product Backlog to reflect the reality that we know today.

Prioritized

The Product Backlog is prioritized when the highest priority items are on top. The Product Owner determines priority by considering both risk and customer value.

The Product Owner will naturally let lower priority items fall to the bottom of the list as they focus on getting clarity around near-term Product Backlog Items at the top. For huge backlogs, it can be inefficient to manage the priority of items that are unlikely to happen within a three-month window. It is not vital to keep the bottom of the backlog organized as long as we know that enough of the top is accurate to cover a couple of Sprints.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

-Agile Manifesto

Achieving a DEEP Product Backlog

In his book Agile Product Management with Scrum, Roman Pichler points out that the Product Backlog needs regular attention. The key to a healthy Product Backlog is to perform refinement regularly.

Although product backlog management is the responsibility of the Product Owner, the whole team can participate in refinement. This collaborative process removes the typical anti-pattern of passing stories to the development team with no context. When we approach refinement as a collective responsibility, there is an intrinsic shared understanding of the required work.

Works Consulted

• Agile Product Management with Scrum: Creating Products that Customers Love
• Make the Product Backlog DEEP (Roman Pichler)
• Make the Product Backlog DEEP (Mountain Goat Software)
• Agile Manifesto

TLDR

Set a cadence for backlog refinement and ensure that your backlog meets qualities identified by the DEEP acronym: detailed appropriately, estimated, emergent, and prioritized. Keeping the Product Backlog healthy and trim will clear the path to success.