• E1: Decompose by performance results and stakeholders –  Break down the work into small (weekly) value delivery steps
• E2: Do high-risk steps early – Prioritize the work based on risk
• E3: Focus on improving your most valuable objectives first – Also prioritize the work based on business value

These ideas became the concepts embodied in backlogs by today’s agile approaches and frameworks.

So, we can trace each approach back to around the same time and also be confident these ideas were firmly established long before that. Building the pyramids and Roman cities required multiple levels of planning, work decomposition and task coordination. There is little point in arguing whether WBSs or backlogs came first since it was clearly lots of other things.

These days, the PMI Practice Standard for Work Breakdown Structures defines a WBS as “…a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the desired deliverables.” The Scrum Guide defines a product backlog as “an ordered list of everything that is known to be needed in the product.”

Are they really so different? They both help with forming an agreement on scope. Yet, due to how they are often used, they are viewed as quite different by many people…a viewpoint I would like to change.

WBS and Backlog Similarities and Differences
Work breakdown structures are often defined upfront and supported with a WBS dictionary. They can be used to form statements of work and contracts. If these deliverables are useful for your projects, then great, create them. However, understand we could create the same deliverables from a product backlog also.

Yet, on agile projects, we typically do not because these environments tend to be more dynamic so these deliverables would soon be out of date. Instead, we create iteration plans, release roadmaps and work from the top of the backlog while the product owner manages the backlog with evolving priorities and change requests. These deliverables are easier to update as changes occur. The differences we see in action stem more from the characteristics of the work environment than the WBS or backlog tool in use. Both help us define and discuss scope.

Visual Benefits
Both are visual and allow us to point at items as we talk about them. This is critically important. Visual depictions of work allow us to collaborate more effectively. When two people face a task board or WBS diagram, they can collaborate with less contention. Visualizations help us build shared understandings and avoid confusions such as having two similar items being considered the same thing or assuming one solution fits two scenarios when it does not.

Depicting scope visually also allows us to shade and color items to indicate type, ownership, risk and completion status.  Visualizing work is a major component of lean thinking. When we visualize something, we also process information using more of our brain—and much more quickly compared to reading and interpreting written information. This is one reason we have road signs with images and not descriptions to read. It is the difference between decoding and understanding meaning in 150 microseconds (roads signs) versus 6,000 microseconds for reading:

Product Backlogs as a form of WBS
The third edition of the Practice Standard for Work Breakdown Structures talks about backlogs as a form of WBS. Many people think only tree structures of boxes and lines are work breakdown structures, but they can actually take on many forms including tabular backlogs or even mind maps.

I can imagine some purists shouting “No, that’s not a WBS!” as I type this, but go check it out for yourself if you do not believe me. The Practice Standard for Work Breakdown Structures WBS is a free download for PMI members. 

I participated as a reviewer for the standard and was pleased to see its coverage of agile scope decomposition using epics, features, user stories and tasks as candidate WBS elements. One thing that puzzled me that I am hoping a reader of this article can help me with is the inclusion of sprints or iterations as potential WBS elements.

My confusion stems from the logical definition of work in section 2.1 that says “… work refers to outputs, work products, or deliverables that are the results of effort, not the effort itself.” – that makes sense. Then in section 2.3.1.1 on WBS rules it says “WBS elements do not account for time or sequence.” Again, that seems reasonable.

However, the examples for agile projects include a WBS with level 2 items showing “Iteration 1,” “Iteration 2,” etc. containing work. This seems to violate the deliverables versus effort definition of “work and no-time” rule. We would not have a WBS element called “September,” so why call out some arbitrary time box? Iterations are just time constructs, and you might choose to use them or work without them as a continuous pull of features from the backlog.

Likely I am interpreting the work, deliverables and no-time rules too literally and, like debating which approach came first,  it probably does not matter. If having iterations shown helps you share your plans and have meaningful conversations about scope, then go for it. I would imagine it would result in having to refactor the WBS frequently as stories get shifted between iterations as priorities change and throughput varies, but maybe not.

The more important idea is that we visualize and discuss project scope with a wide variety of stakeholders to surface and correct misunderstandings. The good news is that product backlogs are a legitimate form of WBS and more of a sibling than a distant cousin. A couple of great quotes from the WBS Practice Standard reiterates the value and applies equally well to backlogs and release roadmaps:

“The WBS provides the foundation for a visual representation of the scope of work…Research demonstrates that communication is one of the project management disciplines with the highest impact on project success. The WBS serves as a critical project communication mechanism that helps convey the scope of the project through its graphical depiction.”

So let’s get graphical and keep communicating.

[Note: This article first appeared on ProjectManagement.com here. For more articles from Mike Griffiths check his blog www.LeadingAnswers.com]