The Product Backlog, an Agile WBS

As one of the community leaders for the PMI Agile Community of Practice – unfortunately nicknamed “COP” – I’ve found myself writing articles that end up behind their log on. This article is one of those such instances. For those of you who are members of the PMI, I would encourage you to join the community of practice, as it is becoming a very vibrant online community of project managers looking to apply Agile values and principles to their craft. For those of you who aren’t, I will cross-post here from time to time. Articles like his I find to be very important in helping to establish that much of the material presented by the PMI is not so much incorrect as frequently poorly applied. In this case, we see that there is nothing in the formal definition of a WBS that would prevent it from being used as a product backlog

There is a classic business problem regaled in business school where the management company of a large tower is struggling to deal with complaints about wait times for their elevators. The company brought in consultants to investigate adding additional elevators and other expensive solutions. Then, brilliantly, someone re-frames the problem from an engineering one to a psychological one. It’s not that the elevators were slow, but rather people perceived they were waiting too long. If you solve the perception problem, then people won’t complain. What did they do? They put up mirrors in the elevator lobbies so that people would be distracted when waiting for the elevator. This novel approach effectively resolved the problem for a fraction of the cost that would have been required had this been viewed purely through the lens of an engineering problem. This is a perfect example of an Agile project leveraging learning in the middle of the project to fundamentally change directions to deliver a better result.

Within software development, we see the same challenge: depending on how we frame a requirement or user need, we may end up with a very different project. Herein lies a key challenge when running an Agile project, if your requirements are not captured in a flexible manner, you will sacrifice a significant amount of value. Had a project been chartered to increase the elevator capacity, as opposed to fix the complaints about wait time, the team would have been unable solve the problem simply by putting in mirrors. Indeed, they may have become contractually obligated to deliver more elevator capacity, locking the customer into a costly solution they did not need.

It’s not that the traditional Work Breakdown Structure is incompatible with Agile projects, but rather that the way we organize our work and use such a structure is crucial to how successful our project is. Let’s take a closer look at how we manage requirements within an Agile project. There are three key concepts we will walk through in detail: requirements should be small enough to fit into a short period of time, they should be prioritized, and they should be based on the user’s perspective.

Align your Work with the Business

By definition, an Agile project is meant to be executed in close alignment with the customer’s needs. Not only should it begin with this alignment, but it should be managed in an adaptive manner such that the project can adjust based on insights gained and changing circumstances. How exactly do we communicate the scope of work and requirements in a fashion complimentary to our goal of being adaptive? Enter the product backlog!

Originating from Scrum, the product backlog is a prioritized list of things needed for the product being built. In its simplest form, this could simply be a force ranked list of features or capabilities. Here is my simple list of features needed for my online book store. You will see that I have identified 6 features and placed them in a forced rank order.

I need to reiterate that when we say prioritized, we don’t mean “high”, “medium”, and “low”. Rather, our goal is an actual ranking, where item one is the single most important thing, item two is the next most important thing, and so on. Prioritizing into buckets leads to games. Have you ever had a project where 90% of the features were “must have”? Me too. If everything is a high priority, then nothing truly is. In fact, it is irresponsible project management. If I can’t tell what features are truly mission critical, I can’t make sure they are properly completed above other features that may not be as important. If you take nothing else from this article, get your customer to force rank their requirements, the clarity you get from this exercise will be invaluable.

The priority of the backlog is critical, as it drives the order in which features are delivered. Those on the top will be undertaken first, and those on the bottom will be deferred until all higher priority items are completed. Some people will refer to these items as “sushi slices” of functionality, where we define a piece of work that consists of a little bite of each type of task, as opposed to defining work items that are large and homogeneous. The image below should help you see what we mean when we say a feature that requires a little bit of each type of task.

This backlog is generally managed by the product owner or whoever is representing the business, and may be changed at any time. The general rule is that the business may change the priority of any piece of work that has not yet been started. Agile projects can benefit immediately from this type of prioritized list by using the progressive elaboration. This allows the team to focus energy on those items that are highest priority and will be done next. Those items that are of much lower priority can remain ambiguous. Simply stated, we don’t need to come up with the requirements or design for the entire system before we can proceed. This allows us to begin building and validating small pieces of functionality rapidly.

Define Work Items Small Enough to Complete in Under Two Weeks

Most Agile projects use some sort of time boxed iteration, where a team will take on work that it can to complete within a time horizon of about two weeks. Teams need to be proficient breaking up large requirements into progressively smaller capabilities to deliver. Smaller pieces of work improve testability and flexibility when prioritizing features. The Standish Group’s 2002 CHAOS report observed that users reported rarely or never using nearly 2/3rd of all features delivered in their systems. Breaking apart requirements into smaller pieces allows us to deliver the 1/3rd that are truly important without being tied to those that are less important.

Building on my earlier example, we may see that something like searching for a book is quite large once you begin to think about all the different dimensions upon which you may run a search. Here I have shown it being broken into four distinct features. What you will also notice is that they are not all of the same priority. Searching by ISBN was actually put on the very bottom of the list and represents one of those features that probably shouldn’t be built, but if we took on all of search as a single work item, very well may have bloated our product.

Frame Work Items on Value for the Business

So now we have an ordered list of things to build for our product that are small enough we could fit them within an iteration of two weeks. That’s great, but it’s not enough. Simply having a list isn’t enough, think back to our elevator problem. They could have easily put together a list that included things like, “run elevators more efficiently” and “add more elevators”. While they could work through those items individually, we’re still focused on a single perspective. Teams frequently fall into this trap, they focus their backlog either on tasks to do or on technical components. Considering that many IT teams are led by project managers or tech leads, its natural they would bring their own bias towards how they look at a project. The challenge being, this is not how the customer thinks about the problem. Rather, we want our work to be focused on the experience of a user, because those are the outcomes we’re trying to influence. Focus on the user also gives us maximum flexibility to plan our work around what the customer really cares about, the experience and outcomes.

There are several different techniques you could use to capture requirements from a user perspective. For purposes of this discussion, let’s talk about User Stories, a practice from eXtreme Programming which is probably also the most commonly used within Agile software development. User Stories are a mechanism for framing requirements from the point of view of a specific user. They contain two parts, a narrative and acceptance criteria. The narrative contains an actor, an action and a justification and the acceptance criteria contains the criteria the business will test to approve a given story. While this structure is pretty useful, the important concept is that we’ve framed each feature as an experience, they are technically agnostic and they each have a business justification, what I would call the “so that” of the story.

For co-located teams, User Stories are designed to be lightweight enough that each one is put on a note card and stuck to a wall. In fact, User Stories are meant to be a placeholder for a conversation,  thus they give enough information for us to get the general idea, but encourage us to go speak to the business to make sure we completely understand. The acceptance criteria helps us nail down very specific criteria we will use for saying a piece of work is complete. Building upon our earlier example, here are the first two features written as user stories

Reconciling the Product Backlog with the Work Breakdown Structure

None of what we have walked through so far is in conflict with what the PMBOK® guide says about work breakdown structures. In fact, a review of the guide will show the following definition:

“The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.” (PMI Project Body of Knowledge® 4th Edition, . 146)

The only difference is that with an Agile project, we expand our horizon of project goals and try to align them directly with the outcomes of the business. Thus, the goal of an Agile project won’t be to implement the XYZ system, but should rather be based on a specific outcome or experience. Beyond that, the same concepts apply. WBS can be progressively decomposed to smaller and smaller deliverables, much like we broke apart the book search feature. The PMBOK® supports the idea of progressive elaboration, so that we have invested a lot of time and detail into those items coming up next, and not a lot on those that won’t be addressed for a long time.

Empowering the Business

So those are the mechanics we use to manage scope and requirements. The real power comes in the way that a business partner can use them to maximize their own success. This article doesn’t have sufficient space to fully explore this topic, but let me offer you a few strategies used by effective product owners and project managers to get the most value out of their agile teams.

  • Prioritize on business value – the team can simply start on the most valuable item and keep working until the law of diminishing returns kicks in and it is not worth working on anything else. This strategy will help a business build a lean product without extraneous features.
  • Prioritize to maximize learning – in some situations where the solution is not fully understood, teams will pursue a strategy of prioritizing work in order to maximize their learning within the domain. You could almost think of this as the scientific method, where a product owner may establish a hypothesis about how to solve a problem, test it and then adjust the theory.
  • Prioritize to minimize risk – good project managers know that if you’re going to fail, fail early. Working with the business, some teams will adjust the order of work in order to deliver those features that are highest risk first. The strategy being that if the project is to fail or encounter severe problems, these are the things that will cause problems. By doing them first, the team has the most amount of time to respond and risks can be confronted and removed earlier from the project.

These strategies aren’t mutually exclusive; teams frequently start with one and transition to another. Many teams will begin by prioritizing to reduce risk and maximize learning, and then as the domain is better known and less uncertain, adjust to a priority based on business value.


A product backlog doesn’t make you Agile, but a poorly designed and managed one will sacrifice a significant amount of potential value from an Agile team. Thus we see that a well used product backlog allows the team to properly align their work around the goals and objectives of the business. It brings that business into a closer partnership by giving them unprecedented transparency into what is being done and in what order. Lastly, it encourages collaboration. Each piece of work the team undertakes is tied to business outcomes and justification, inviting the business to partner much closer with the team working to deliver the project. Ultimately our goal is to deliver value for our customer, the more we can empower them to make decisions best representing their interests, the more value we can deliver.