WBS vs. Backlog

Some of the most popular questions in the project world - and, of course, in the process of agile evolution - reveal a kind of rivalry between the WBS and the Backlog. While that fight is a bit silly, in my humble opinion, here are some of the questions I’m going to answer below:

1. Is it better to build a WBS or a Backlog?
2. Why don’t agile projects - run with Scrum or XP - have a WBS?
3. How can I plan a project if there’s no scope defined in a WBS?

Here I’ll answer all of these questions - and a few more - to help you understand the Work Breakdown Structure (WBS) and the Backlog .

What Is a WBS?

In a project context, a work breakdown structure (WBS) is, by definition, a hierarchical decomposition of the total scope of work to be carried out[ref]Based on the most recent definition given by the Project Management Body of Knowledge, or PMBOK version 7 [/ref].

The WBS is a powerful, useful tool in contexts where it’s possible to commit to the total scope of work. But what happens when it isn’t possible, or practical, to commit to the project’s scope?

WBS: A Key Tool in Predictive Environments

Many project managers believe that being unable to commit to the total project scope is a planning or analysis problem. And while bad planning does cause plenty of problems, the WBS isn’t a foolproof tool.

The WBS is very useful - and only useful - where the planning context is predictable . That is, where our estimates and “predictions” of what’s going to happen have a high probability of actually occurring.

Let’s look at an example. If you throw an apple up in the air, you can be pretty sure it’ll come back down at some point. Sure, we could imagine someone catching it mid-air, or aliens showing up and grabbing it with a tractor beam, but the truth is, with almost 100% certainty, we know the apple is going to fall. If you remember projectile motion from school, you can even calculate where it’ll land. That’s how we launch rockets into space and recover astronauts when they come back. We can predict, with a high degree of certainty, what’s going to happen.

That’s where the WBS - the breakdown of the total scope - is very useful. Using the WBS well helps mitigate risk and plan better. But what about a different environment, where it isn’t possible or practical to anticipate the outcome?

WBS: More Problems Than Benefits in Complex, Adaptive Environments

Imagine a project where you don’t have a closed scope. Some control-obsessed folks will say: how can a project even exist without a closed scope? To make my point, let me share an anecdote.

Challenges in Adaptive Environments

Years ago, in one of my classes for a master’s degree cohort, we covered the concept of adaptive projects and the need for project management models where scope isn’t defined, isn’t entirely clear, or where, even when it is defined, we expect it to change.

One of the students came up to me and said something like: “This is the first class in this whole master’s program that actually makes sense for my job,” and went on to explain that, for her, the WBS, the detailed activity schedule, and the budget - the result of that breakdown and schedule-building, a TOP-DOWN approach - made absolutely no sense.

Why did she say that? She worked in scientific research, and explained that the biggest problem was that these “predictive” concepts were also required by the entities that allocated research funding. For her and her team, getting access to research funding meant presenting a detailed activity schedule and a budget.

How Do You Run Variable-Scope Projects Without a WBS?

The need to run projects without a closed or defined scope is real, and the methodological problem behind it isn’t minor. We see it in scientific research, but also in innovation areas. Could we ask an innovation team to present a detailed activity schedule at the start of the year? Or in marketing, advertising, or brand management - could we anticipate how the public will respond to a particular topic? What happens if there’s no time to run market studies?

That’s why, in these kinds of scenarios, we use more flexible, less predictive structures. That’s where the Backlog comes in as one of the alternatives.

Why Doesn’t a WBS Work Like a Backlog?

Let’s go back to the definition of a WBS: a hierarchical decomposition of the total scope of work. That’s the key phrase - total scope, and hierarchical decomposition.

Four Differences Between the Backlog and the WBS

1. Scope. Everything included in the WBS needs to be completed to complete the project. The Backlog, on the other hand, can contain items - low-priority ones - that never end up getting delivered.
2. Priorities. The WBS doesn’t set priorities, so work gets optimized based on the logic of how the deliverable gets resolved or built (production process optimization). The Backlog gets optimized based on business value, which means it’s sometimes possible to build something, and then “build it differently” or “change it” to increase its perceived value.
3. Structure. The WBS is hierarchical, and while it’s not a hard rule, many people use that hierarchy to define phases, or comparable levels - level 0, the final deliverable; level 1, project components or phases; level 2, control accounts, and so on. The Backlog, despite what a lot of people might say, can hold items of very different natures: user stories, epics, fixes, enhancements, use cases, one-off requirements.
4. Business value. A lot of people include, within the WBS - more specifically, the WBS dictionary - the cost of completing a given breakdown component or element. The Backlog can also include that cost - there’s no rule against it - but it’s prioritized based on value, the benefit it represents. Cost and value aren’t always the same thing - something cheap to build can be very valuable to the business, and vice versa.

We could surely talk about other differences, but these are, in my opinion, the key ones.

Is a WBS or a Backlog Better?

Neither one. The WBS is key and very useful if your project needs control over scope - what gets done, what doesn’t, and when we get to discuss whether we’re changing either of those two answers.

The backlog, meanwhile, promotes adaptability. So if your project’s scope is going to change, or depends on feedback cycles to adjust scope, you need a backlog, and maintaining a WBS can become a real headache.

Can You Use a WBS and a Backlog at the Same Time in a Project?

At first glance, someone might say… HOW SILLY. But the truth is it’s possible, and sometimes even necessary. Imagine a large project where part of one of its components is developing a mobile app. Even though the project is bigger and includes, say, sales force training, launch events and promotional activities for the product, and other predictable activities, the development work itself - which could be seen as a work package or a control account - could be managed dynamically, while keeping duration and cost fixed within the plan.

It might seem “tangled up,” but are projects ever really simple? We don’t always get the textbook scenario of 100% predictive or 100% agile projects. In fact, I hope that “distinction” disappears in the future, since it only promotes more division.

How Do You Estimate the Cost of a Project Without a WBS or a Closed Scope?

And well, we’re still on the hard questions. There’s more than one right answer, but let’s go with the most likely option.

If a project has to start without a closed or fully defined scope, the best approach is to set a time and budget limit to validate a result - a business or social one. For example, when we discovered as a society that we needed to work toward a vaccine for a new disease, many governments and private companies set aside a fixed amount of money - a budget line - and gave labs deadlines or time windows to present results.

These “fixed” cost-and-time projects are managed with the intent of “maximizing” the benefit. In other words: I don’t know what’s going to come out of all this, but it’ll be the best result we can get with the time and resources we’ve been given.

That means some labs were able to find the vaccine, and others simply didn’t, and their projects got canceled.

While some might call this approach a matter of “luck,” in a lot of contexts - like entrepreneurship and innovation - it’s the only logical, consistent model.

What matters here is being strict about at least one of the constrained variables: budget or scope. Otherwise, you’ll end up with a project that never ends, makes no commitments, and delivers no results.