The product development backlog is a big, bloated, unwieldy todo list. As time goes no, it becomes difficult to distinguish the good ideas from the bad ideas. The backlog ceases to be a cohesive agenda and vision. So much energy is needed to decipher the backlog that it gathers a momentum of its own. The "like to haves" and low priority improvements are a form of cognitive pollution. This stuff has got to go.
The backlog is a construct to focus intent on an important task that all-too-often gets overlooked: removing low value issues from the backlog. As I'll explain, there are significant benefits to the system: greater predictability, higher morale, and the delivery of greater business value. It is important to use this construct because it encourages us to face an uncomfortable truth, we can't do everything.
There has been a general recognition in product development circles that work in process (WIP) is the invisible economic destroyer. WIP is extremely destructive because it saps energy from the system and diverts the remaining energy away from the highest business value. It results in waste in the form of poor quality outputs, a reactive culture that stifles innovation, increases cycle time, and promotes dangerously high utilization. (Reinertsen, The Principles of Product Development Flow)
Kanban teaches us to limit WIP to reduce to reduce waste and increase flow. But what do we do when our input is greater than our output at the point of origin? In other words, what do we do when our product backlog is filling up with new product backlog items (PBIs) faster than our ability to complete them? My answer? Add a drain to your product backlog.
Three benefits back this up:
- it sets proper expectations upfront
- it eliminates holding cost
- it reduces pressure to trade long-term value for short-term value
The Drain
Before we go on, let me explain what I mean by a "drain".
What is it?
The Drain is the outlet where lowest priority PBIs go. At the end of the Drain is your resolution statuses of "deferred" or "won't do". Just like a tub with the water running, the drain should be regularly unstopped by the Product Owner / Queue Manager so that she achieves a calibrated level of input in the system.
The drain is just a simple concept to formalize the practice.
Construct (Noun) an idea or theory containing various conceptual elements, typically one considered to be subjective and not based on empirical evidence.
Constructs are helpful because they crystalize theories into something that makes it easier to engage. Agile frameworks are full of constructs: product backlog, workstream, feature, etc. But Agile frameworks are missing this important component, a construct a drain.
The Backlog - your starting queue
Think of your backlog as a reservoir with an incoming river at one end and a dam at the other end. Your dam is set to release water from the reservoir a the pace at which the river on the other end is able to accommodate. Set properly, the dam's allows the ideal flow out. The Dam is a control like a WIP limit.
For many product development systems, the only outlet for work items is to the workstream. Scrum and Kanban teach us to release the highest value items to the worksteam. This is visualized by a prioritizing our product backlog.
[caption id="attachment_1803" align="aligncenter" width="600"]
Standard Product Development Visualization of Flow[/caption]
The problem comes into focus when you acknowledge the economic reality, in a system of scarce resources, demand will always exceed supply. In other words the input of new product backlog items almost always exceeds workstream output. If nothing is done the Backlog will continue to grow.
Add a Drain
I'm advocating you leverage another outlet other than the workstream. The function of the drain is to remove the lowest priority PBIs until you have calibrated a level that is optimal for the system. The job of the Product Owner / Queue manager would be to operate that drain on a regular cadence similar to the release of PBIs to the worksteam.
[caption id="attachment_1805" align="aligncenter" width="600"]
The drain is a mechanism for removing the lowest priority PBIs from your backlog[/caption]
Okay, now with the objective out there, lets go into why its a good idea.
Set Expectations
Most PBIs are created (at least in part) by forces outside the production system that manages the backlog. This may include stakeholders, customers, or even product managers removed by level from the particular backlog.
When these PBIs are created and accepted into the backlog we set the expectation, implied or otherwise, that they will be fulfilled. This expectation is a pressure to the system. Left unaddressed that pressure builds. Left long enough, a sense sets in that the systems has somehow "failed to respond".
Draining the system of issues that can't be addressed relieves the system of that pressure.
It also allows the system to set clear expectation for issues that are retained. A system at equilibrium with inputs and outputs can predict a time to complete, even for issues still in the backlog. If you have no drain, there is no way to distinguish between issues you will do and issues you won't do.
Eliminate Holding Costs
Queues are invisible, but as TPS, Lean, Queuing Theory and others have taught us, even invisible knowledge assets (inventory) carries a holding cost.
In product development, as new PBIs arrive and business context changes, queue managers must review the backlog and reshuffle priorities. The longer the backlog, the more energy and time is required to do this. Without a drain the holding cost from prioritizing the backlog continues to grow at an accelerating rate.
In addition, as items age there is a greater possibility that requirements need to be updated to reflect current business context. Without a drain, the average age of items in the backlog will continue to increase, the more items need to be updated and at a greater frequency. An aging product backlog also represent a growing holding cost.
As queues eventually become unmanageable, there is a pressure to shift the burden downstream allowing items with out of date work descriptions to cause disruption in flow or negative outcomes.
Morale is yet another cost of queues. Granted this is hard to quantify, but since it is generally accepted consequence of queues I'll note it here as a component holding cost of product backlog queues.
Focus on the Long-Term Goals
When work builds beyond capacity, we have a natural human instinct to prioritize short-term at the cost of the long-term.
In product development this often shows itself as utilization at a dangerous level, diminished quality, lack of innovation, and a generally reactive product development culture.
To flip the script you need to be able to control your queue size to reflect the combination of your business priorities and realistic ability of your system to achieve them.
We can mask the conflict of resource scarcity by deferring work whose consequences will only be felt in the long-term. In the short term we won't notice the choice we've made. In the long term, we may forget we had the choice at all. This happens so regularly in product development that we might not even realize what a big problem it is. Failure to achieve long-term results is often passed off after the fact as the inevitable reality of resource constraints.
Summary
Ultimately The Drain is just a construct: mental tool we can use to help us recognize and overcome a common pattern that keeps us from being awesome. If our product development practice is already great at practicing regular rigorous backlog pruning to eliminate waste, then you probably don't need it. But if you're like many product development shops struggling with the willful blindness that an overflowing product backlog is a symptom of, then perhaps introducing The Drain will help.
Agile is about discovering new ways to think and work. I hope this one invites improvements to your practice.