WBS vs. Backlog

Some of the most popular questions in the project environment and, of course, in agile evolution processes show a rivalry between the WBS and the Backlog. Although this fight is a bit silly in my humble opinion, here are some of the questions I'm going to answer next:

Is it better to develop a WBS or a Backlog?
Why don't agile projects - run with Scrum or XP - have a WBS?
How can I plan a project if there is no scope defined in a WBS?

Here I'm going to answer all these questions - and more - to help you understand the Work Breakdown Structure (WBS) and the Backlog.

Content Table

What is a WBS?

In the context of projects, a Work Breakdown Structure (WBS). By definition, the WBS is a hierarchical decomposition of the total scope of work to be carried out^[1]Based on the most recent definition given by the Project Management Body of Knowledge or PMBOK version 7.

The WBS is a powerful and useful tool in contexts where it is possible to underwrite the full scope of work, but what if it is not possible or practical to underwrite the scope of the project?

WBS: Key tool in predictive environments

Many project managers believe that the inability to subscribe to the full scope of the project is an analysis or planning problem. And while poor planning often causes many problems, the WBS is not a foolproof tool.

The WBS is very useful - and only there - where the planning context is predictable. That is, where our estimates and "predictions" of what is going to happen have a high probability of occurrence.

A picture of an apple in someone's hand - as if they were ready to throw it up in the air.

Let's look at an example. If you throw an apple up in the air, you can be pretty sure that it will come down at some point. Sure, we could imagine that someone catches it in mid-air or that aliens arrive and catch the apple with a gravitational beam, but the truth is, with almost 100% of certainty we know that the apple will fall. Even if you remember the parabolic motion from school, you can calculate where it will fall. So we launch rockets into space and retrieve astronauts on their return. We can predict, with a high degree of certainty, what will happen.

There the WBS - the total scope breakdown - is very useful. Good use of WBS helps to mitigate risks and plan better. But what about a different environment where it is not possible or practical to anticipate the outcome?

EDT: More problems than advantages in complex and adaptive environments

Imagine a project where you don't have a closed scope. Some control freaks will say how is it possible for a project to exist without a closed scope? To clarify my point, I'll go with an anecdote.

Challenges in adaptive environments

Several years ago, in one of my classes for a master's group, we looked at the concept of adaptive projects and the need to establish project management models where the scope is not defined, not at all clear, or where despite being defined we expect it to change.

One of the people in the class came up to me and said something like this: "This is the first class in this master's class that makes sense in my work", and went on to explain that for her the WBS, the detailed schedule of activities, and the budget - as a result of such a breakdown and construction of the schedule, TOP-DOWN approach - was real nonsense.

The reason for this statement? She worked in scientific research, and explained that the most serious problem was that these "predictive" concepts were also required by the entities that allocated research resources. For her and her team, accessing research resources required the presentation of a detailed schedule of activities and a budget.

How to do variable scope projects and not have a WBS?

The need to carry out projects without a closed or defined scope exists, and the methodological problem is not a minor issue. We see it in scientific research, but also in areas of innovation. Could we ask an innovation area to present a detailed schedule of its activities at the beginning of the year? Or in areas of marketing and advertising, or image management, could we anticipate the public's response to a particular topic? What if there is no time to do market research?

Therefore, in this type of scenarios we use more flexible and less predictive structures. This is where the Backlog as one of the alternatives.

Why doesn't the WBS work as a Backlog?

Let's go back to the definition of WBS: hierarchical decomposition of the total scope of work. This talks about total scope and hierarchical decomposition.

Four differences between the Backlog and the WBS

The scope. Everything included in the WBS must be completed to complete the project. The backlog, on the other hand, may contain items - low priority items - that are never delivered.
Priorities. The WBS does not establish priorities, therefore, the work is optimized according to the logic of resolution or construction of the deliverable (optimization of the production process). The Backlog is optimized according to the value for the business, this means that sometimes it is possible to do something and then "redo it differently" or "change it" to increase the perceived value.
Structure. The WBS is hierarchical and, although it is not a golden rule, many use such hierarchy to establish phases, or comparable levels - i.e. level 0, final deliverable, level 1 components or project phases, level 2 control accounts, and so on. The backlog, despite what many would like to say, can have elements of different nature such as user stories, epics, fixes, enhancements, use cases, point requirements.
Business Value. Many people include within the WBS - more specifically the WBS dictionary - the cost of doing a certain component or element of the breakdown. The backlog may include that cost - there is no prohibition against it - but it is prioritized based on the value - the benefit it represents. Cost and value are not always the same, something inexpensive to do can be very beneficial to the business, and vice versa.

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

Better a WBS or a backlog?

Neither. The WBS is key and very useful if your project requires you to have control over the scope - what gets done, what doesn't get done and when we discuss if we change either of these two answers.

The backlog on the other hand promotes adaptability. So, if your project is going to change scope or rely on feedback cycles to adjust the scope, you need a backlog and keeping a WBS can be a headache.

Is it possible to use the WBS and the Backlog at the same time in a project?

Although at first glance someone might say... WHAT NONSENSE. The truth is that it is possible, and sometimes necessary. Imagine a big project where part of one of the components is the development of a mobile application. Although the project is larger and contemplates, for example, sales force trainings, events and promotional product launches and other predictable activities, the development itself - which could be seen as a work package or a control account - and managed dynamically leaving the duration and cost fixed within the plan.

It may seem a bit "convoluted" to you, but are projects all simple? We don't always have the scenario in the book that talks about 100% predictive or 100% agile projects. Moreover, in the future, I hope that such "differentiation" will disappear as it only promotes more division.

How to estimate the cost of a project without a WBS or closed scope?

And well, we continue with the difficult questions. Although there is more than one correct answer, let's go with the most likely option.

If a project must start without a closed or fully defined scope, it is best to set a time and budget limit to validate an outcome - business or social. For example, when we discovered that we should as a society work on a vaccine against a new disease, many governments and private companies set aside a fixed amount of money - a budget line item and gave labs deadlines or time slots to submit results.

These "fixed" cost and time projects are managed with the intention of "maximizing" profit. That is, I do not know what will come out of all this, but it will be the best result we can in the time and with the resources allocated.

This means that some laboratories were able to find the vaccine and others simply did not succeed and the projects were cancelled.

Although for some it may be a "lucky" approach, in many contexts, such as entrepreneurship and innovation, it is the only logical and consistent model.

Here the important thing is to be strict with some of the variables under restriction, the budget or the scope. Otherwise, we will find ourselves in a project that has no end and that does not assume commitments or deliver results.