In one of my recent PMI-ACP classes, I was asked if the Product Backlog is the equivalent of the Work Breakdown Structure (WBS) for Agile projects. That was an interesting question that made me reflect before providing my student with an accurate answer.
Work Breakdown Structures are an important piece in the planning phase of a predictive project. It is a diagram that lists all elements of the scope of the project and shows them together in a structured and hierarchical manner. It reduces the risk of having scope creeps (why again are we working on this hardware piece that was not originally part of the project scope?) and the risk of forgetting something important (oops, did anyone remember to train the support team?) in the project.
Good Work Breakdown Structures explain well the scope of a predictive project and are part of what we call scope baseline. The baseline serves as a solid reference for the entire team. A reference that, if changed, requires a new version number and triggers a series of change management activities to ensure a nice cohesion between all other parts of the project plan.
A product backlog of an agile project is also the main reference of the project scope used by the project team. It is composed of parts that will eventually be executed (through sprints, for example) and, once completed, will be marked as done. Just like the elements of a WBS.
However, a product backlog differs from a WBS in at least a couple of critical aspects:
Items in the product backlog are as independent of each other as possible while items of a WBS are linked to each other in a structured manner.
The product backlog is often composed of parts called user stories. And good user stories need to fulfill the “INVEST” rule, an acronym that stands for Independent, Negotiable, Valuable, Estimable, Small and Testable. Without expanding too much on this acronym, the first letter is what interests us here: the various components of a product backlog need to be independent of each other because they need to be prioritized and re-prioritized within the product backlog. So if they have links between each other (example: I can’t do this without doing that before), the level of flexibility for the prioritization activity becomes very limited.
The WBS is the baseline of the project so pretty much a document that is not supposed to change much while the product backlog is a live document and evolves continuously throughout the project life.
The product backlog is the master list of pieces that we want to develop in our project. There is only one product backlog for each project. However, the product backlog is a live document. It evolves on a continuous basis since the customer (or product owner) has the freedom to remove items from the backlog or add items to it almost as often as they change clothes. That’s OK because the team welcomes this dynamic. Welcoming change is the heart of the agile mindset. A WBS is also the master list of project parts that serves as the reference for the team but it can not change as we wish. Changes in the project scope need to follow a pre-adopted process to be accepted and then incorporated into the WBS.
These differences don’t mean that WBS’s are less useful than product backlogs. Not at all. Some projects need the level of structure and governance that a WBS in a predictive context brings to them. Others will benefit more from a flexible way of working that a product backlog in an agile environment provides. Agile methods are not necessarily better than predictive methods, they just fit better in certain contexts.
In summary, it is hard to see a WBS and a product backlog co-exist in a project. They are so different in the way they work that they look like cousins that don’t talk to each other: you do like both of them; you just don’t invite both to the same barbecue.
