Many organizations steeped in traditional project management culture struggle to adopt Agile’s product management approach.  One of the biggest cultural stumbling blocks is the difference between how traditional project management and Agile treat project scope.  This is best exemplified by the differences between the Work Breakdown Structure (WBS) and Scrum’s concept of the product backlog.  This article describes both tools, compares and contrasts them, and makes the case for not conflating these two methods of accounting for project scope.

What is a WBS?

The PMBOK® Guide—Third Edition defines a WBS as:

“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. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.”

PMBOK® Guide—Third Edition

A WBS is a planning tool that helps identify, document, and present the total scope of a project.  Scope is one of the three project management constraints colloquially known as “The Iron Triangle”.

The Iron Triangle represents how scope, schedule, and level of effort/resources act as mutually-dependent project constraints.  Traditional project management attempts to predict most, if not the entire, project scope prior to project execution.  Later, planners estimate the level of effort required to complete planned tasks and deliverables and build a project schedule based on those estimates.  The resulting three values feed calculation of project cost.

WBS Structure

A WBS is most often depicted as a hierarchical tree.  Every node in the tree is called an element.

Depending on the type of WBS hierarchy created, project scope may be organized in terms of:

• Project/program activities necessary to deliver deliverables (Verb-Oriented)
• Product components that make up a deliverable (Noun-Oriented)
• Time-bound phases of the project plan
• A mix of the previous three types

The root of the tree (WBS level 1) represents the entire scope of the project or product deliverable.  From there, the main branches/elements of the tree (WBS Level 2) are structured in accordance with one of the four types of WBS hierarchy types listed above.

WBS Decomposition

The tree expands as higher-level elements are decomposed into smaller constituent elements or components.  Each element represents 100% of planned work and deliverables for that element.  Child elements collectively represent 100% of the scope represented by their parent.  Decomposing across elements just enough to facilitate project scope definition, without over-specifying the project or solution, while accounting for the entirety of project scope, is an art honed by experience.

Mapping to schedule and Resources

At the lowest level of each branch of the WBS hierarchy are work packages.  Work packages map project scope (deliverables and activities) to project schedule.  A work package includes schedule activities and milestones required to complete the associated deliverable or work element/component.  In turn, control accounts map work packages to project budget (cost), facilitate the roll up of activities and milestones into an integrated schedule, and allow planners to assign specific resources (e.g., people) to specific elements of the WBS hierarchy.

Another artifact that ties the scope represented by the WBS to project schedule and resources is the WBS dictionary.  The PMBOK® Guide—Third Edition defines a WBS dictionary as:

A document that describes each component in the WBS.  For each WBS component, the WBS dictionary includes a brief description of the scope or statement of work, defined deliverables, a list of associated activities, and a list of milestones.  Other information may include responsible organization, start and end dates, resources required, an estimate of cost, charge number, contract information, quality requirements, and technical references to facilitate performance of the work.

PMBOK® Guide—Third Edition

The WBS dictionary for figure 3 above may look something like this:

Types of WBS Hierarchies

Let’s delve a little deeper into the different types of WBS hierarchies.

Project Scope WBS

A project scope WBS decomposes the project work or activities necessary to produce deliverables or products.  The first word of each WBS element name is a verb, such as, design, develop, test, etc.  In figure 4 above, the project is organized by Software Development Lifecycle (SDLC) phases (Define, Design, Develop, and Integrate & Test) and includes the project management work necessary to orchestrate the work.

Product Scope WBS

A product scope WBS defines project work in terms of the components (physical or functional) that make up a deliverable or product.  In this case, the first word of each WBS element name is a noun, such as, Module A, Subsystem B, Aircraft Engine, Fuselage, etc.  Since each element represents a part of the overall product, this WBS type is sometimes called a “Product Breakdown Structure (PBS)”.

Time-Phased WBS

Large-scale projects can take years to complete.  In such cases, it is reasonable and advisable to break up project scope and schedule into discrete phases.  A “time-phased” WBS breaks up the project into major phases instead of activities.  Rather than planning the entire project upfront, planners follow a “rolling wave” planning approach in which they plan the upcoming phase in detail while postponing detailed planning for later phases.  Rolling wave planning affords the opportunity to improve current plans based on lessons learned in previous phases. It also provides a measure of flexibility to deal with changing project realities.

Hybrid WBS

Elements from the three other WBS types can be combined to create a “hybrid” WBS.  Defense materiel project planners frequently use this type of WBS.  Such projects tend to be long-lived, so time-phased branches may be included.  Product-based branches scope complex products/deliverables.  For activities that map to specific activity phases (e.g., SDLC phases), project scope elements are appropriate.  A hybrid WBS may include project or program activities outside the scope of creating physical or functional product components or managing their creation.  Examples of such activities include training, operations & maintenance, and facilities management.

WBS Type Comparison Chart

I summarize the WBS hierarchy types in the table below:

Agile Value Delivery

Before discussing product backlogs, I need to explain how Agile software teams deliver useful capabilities. 

Agile software teams deliver iteratively and incrementally.  They release valuable increments of software functionality over the entire development effort.  These increments are “production ready” or “potentially releasable” software capabilities that customers and end users can start using right away.  While not everything released by Agile teams must be user facing, they avoid releasing individual system components or portions of components that do not deliver real business or mission value on their own.

Solutions built by Agile teams grow and evolve over time.  Each and every increment delivered is designed to work with all other increments, past and future.

Thus, Agile releases are primarily feature-based, not component-based.  Rather than delivering system components, Agile software teams strive to deliver features.  Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users. 

What is a Product Backlog?

A product backlog is an ordered queue of deliverables.  The term product backlog is most associated with the Agile framework called Scrum.  According to the Scrum Guide, the product backlog:

…is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

https://www.scrumguides.org/scrum-guide.html

In this definition, the “product” is whatever the Scrum Team develops and delivers (application, system, solution, documentation, reports, etc.). A product backlog is used to track product deliverables.

As depicted in figure 9 below, Scrum teams take into account multiple considerations when ordering product backlog items.

Learn more about ordering product backlogs.

Product backlog items represent features.  Scrum teams decompose bigger features into smaller ones to better manage their development.

The highest-ordered items are most ready for implementation.  The Scrum Team refined them well enough to implement them.  Lower-ordered items are increasingly less ready for implementation the further down the product backlog they rank.

Comparing & Contrasting WBS vs. Product Backlog

Having level set what a WBS and product backlog are, I now discuss the similarities and differences between them.

Similarities

Of the four WBS types discussed in this article, the PBS is most like a product backlog.  Both are product scope-focused and decompose larger deliverables into smaller ones.

Neither a WBS or product backlog depict dependencies between elements or items.  The main artifact used to show dependencies between work activities and deliverable milestones in traditional project management is the project schedule.  User story maps help organize Scrum product backlog items (epics and user stories) based on workflow and interface dependencies.

Differences

The main difference between WBS hierarchies and product backlogs is that the WBS is a tool for linking together project scope with the other two Iron Triangle constraints:  schedule and level of effort/resources.  A product backlog is strictly focused on tracking and ordering product scope.

Modern Agile productivity tools like JIRA allow development teams to document the work they perform, how long it takes them to do it, etc.  However, that information is collected after developers pull the highest priority items from the product backlog and begin work.  The product backlog is neither a repository for nor a source of work status information.

Another difference is that tasks and activities count as part of the scope represented by a WBS (e.g., project management tasks, meetings, reporting).  While Agile software teams also deal with management and project overhead, those activities are not included in the product backlog.  From an Agile perspective, those activities are not part of the product.  They are necessary, yet ancillary activities to the work of developing, testing, and releasing software.

Finally, product-oriented WBS elements represent components while product backlog items represent features. 

Disadvantages of Decomposing Product Scope into Components

Decomposing product scope into components has three major disadvantages:

1. Postponing integration and testing
2. Difficulty measuring progress
3. Formation of component team silos

Postponing Integration and Testing

In traditional software projects, there is often nothing valuable to test and evaluate, from a business or mission perspective, until most or all components are integrated into a cohesive solution.  In traditional software projects, system integration is done infrequently, often occurring only once towards the end of development.  Integrating components towards the end of a project often affords insufficient time to address problems.

Difficulty Measuring Progress

Traditional project management focuses on tracking tasks and activities and their level of completion (e.g., percentage complete).  The rationale being that if everyone executes all necessary tasks and activities, on time, and in the right order, the project will proceed as planned.  Therefore, project management’s job is to identify everything that needs to be done before the start of the project and enforce adherence to the plan. 

The problem with applying this approach to software projects is that non-trivial software systems are significantly more complex than physical systems of comparable cost.  This is because software systems can be developed and modified in infinite ways.  As software systems evolve to serve growing numbers of requirements from growing user bases, their complexity increases, sometimes at a seemingly exponential rate.  No amount of predictive planning can overcome this natural slide towards entropy.

There is also the issue of quantifying how much actual progress has been made.  What is the difference between a component being 75% complete vs. 95% complete?  If we have to wait until it is 100% complete and integrated into the larger solution before we can test and validate it, there is none.

Agile planning is adaptive, with short project planning horizons.  Software development teams achieve fast and frequent releases by keeping releases small.  Planning and releasing this way allows for more opportunities to test and validate deliverables and to fold lessons learned into ongoing planning.  Best of all, the measure of project progress is delivery of valuable capability to customers and end users rather than arbitrary estimates of completion rates.

Formation of Component Team Silos

Each WBS element maps to a set or resources (one or more teams) that do the work.  Establishing development teams for specific solution components often stifles cross-team collaboration and creates productivity bottlenecks.

For example, project management forms a dedicated database team to deliver a system database identified as a WBS component.  The result is that the team’s allocated hours and skillset are segregated around delivering a single component.  Often, the inefficiencies of managing dependencies between component teams outweigh the efficiencies gained from component team specialization.

Forming teams around system features is a staple of Agile software development. While component teams are sometimes necessary in Agile software development efforts, the default bias is towards forming feature teams. Under feature teams, system components form and evolve incrementally and iteratively, one feature at a time. Value delivery no longer depends on delivering the entire system. Instead, value delivery occurs one release at a time throughout development.

Agile Breaks the Iron Triangle

To achieve project agility, Agile breaks the Iron Triangle by making project scope variable while fixing resources and schedule.  This involves shifting our thinking about managing projects:

The most optimal solutions reside in the nexus of value, cost-effectiveness, and timeliness:

Agile projects control scope and ensure teams satisfy requirements through ongoing planning and collaboration between development teams, project sponsors, stakeholders, customers, and end users.  Sponsors control budgets and approve project roadmaps; stakeholders, customers, and end users work with development teams to define solutions; and development teams plan and build functionality within those constraints.  The advantages of controlling projects primarily through managing project scope are:

• Not sacrificing quality in favor of adhering to all three constraints of the Iron Triangle.
• No budget or schedule surprises (since budgets and schedules are essentially fixed)
• Basing project decisions on the actual business or mission value delivered and team performance rather than alignment to detailed (and possibly obsolete) plans

Conclusion

At the heart of the differences between traditional project management and Agile is the fundamental difference between project management and product management.  Project management focuses on managing tasks and activities to ensure they complete on schedule and on budget.  Product management focuses primarily on managing the product.

Many project and program managers are unaware of this difference.  Implementation of Agile practices corrupted by traditional project management biases often leads to failed projects.  Attempting to structure product backlogs like WBS hierarchies is one manifestation of this misalignment between traditional project management and Agile mindsets.