I recently finished a certified LeSS (Large Scale Scrum) practitioner course and was particularly intrigued by the principle of Whole Product Focus. It emphasizes that customers don’t buy a part of a product, they buy the whole product.
Whole Product Focus
In the course, we used the example of a car. A navigation system alone doesn’t meet a car-buyer’s needs; instead, the navigation system is a feature that makes the entire car more valuable. If the “navigation system team” completed their part of the work quickly, it would not make the car any more shippable. If the project got shut down with nothing delivered but a rock-solid navigation system, there would be zero value for customers searching for a whole car. This would be true even if the navigation system team was doing a perfect job of prioritizing their items and delivering them on time.
The failure in this example is obvious: optimizing the work on the navigation system means nothing; what matters is the entire product, the car. The efforts of the various teams—those responsible for the body, the chassis, the engine and transmission, etc.—all have to be integrated and come together to ensure a successful product delivery. LeSS recognizes this and emphasizes its importance by recommending a single product backlog that encompasses all work necessary.
Alignment of Vision
A shared backlog has the added side effect of aligning the overall vision. If the teams tasked with delivering the auto body and internal engine components find themselves in need of resources or otherwise blocked by impediments, folks on other teams may be able to jump in and help. It becomes less clear where our efforts should be focused when there are multiple backlogs being worked in parallel. With a better understanding of overall project priorities, we always deliver the most valuable product increment.
Single Backlog in Practice
LeSS, therefore, recommends one common product increment, one common sprint, one Product Owner, and – yes – one shared backlog across all teams. When the idea of a single product owner was introduced in the class, it led to a fun discussion about whether it is truly practical. A single backlog with a single owner conjured the idea of potentially hundreds of teams attempting to self-organize around one to-do list. This excerpt from Kenneth Rubin’s Essential Scrum outlines the problem and explains why organizations naturally gravitate toward multiple backlogs. Rubin notes that putting hundreds of teams’ worth of backlog items into one backlog “isn’t practical or necessary.”
Most of us have worked (or are working) in environments where multiple teams worked toward a common goal but each pulled from their own backlog and interacted with their own PO, so I’m sure you know what that looks like. I’m in that situation right now. The question I pose is how can we be sure we are working on the “right” things when product ownership is decentralized in this way? What if the most valuable use of our resources is for the entire department to work one team’s backlog?
Can It Really Work?
Fortunately, in my current situation, all of the teams share a common roadmap of epics (essentially features). The challenge is that once a team selects an epic and breaks it down into user stories, we are unlikely to ever revisit those user stories and move them from one team to another. Going back to the car example, ideally, you would want all of the teams swarming on a single backlog that defined the minimum viable product for the car. If there is a quick win for the navigation system in a user story or two, maybe they make their way up the priority list, but treating the navigation system as a separate product with its own team limits our ability to shift our attention to the car backlog. We want to assemble cross-functional teams nimble enough to pull items from different epics as priorities evolve.
While I feel a single backlog for a product is ideal, I understand the argument that large, complex products with massive backlogs can be too cumbersome for a single PO. However, a single, massive backlog can also be problematic. Andre Theus’ 5 Signs Your Product Backlog is a Black Hole lists some great suggestions for cleaning up a backlog. I particularly like his description of what a good backlog should be: “…every item on the backlog is clear and easy to understand. Items should earn their place on the list, be slated for near-term action and be prioritized appropriately in relation to other items. And just as important, nothing should be on the backlog that doesn’t belong there.” I believe that splitting the backlog is just a band-aid solution for a flawed backlog. Remember that the V in INVEST stands for Valuable. Is your backlog a collection of tasks to delegate or is it truly a prioritized list of valuable additions to the product?
Less Is More
LeSS stresses simplicity, descaling rather than scaling and removing waste rather than adding complexity. To me, a single product backlog managed by a single product owner drives this philosophy home.