Career Development in Overdrive
Problem Solving: Using Visualization

WBS and Product Backlog: Siblings or Distant Cousins?

WBSandPBIt’s easy to believe that work breakdown structures (WBS) have been around since the pyramids were built in Egypt, and that product backlogs are new inventions by youngsters in too much of a hurry to plan correctly. However, like most things, the truth is more complicated.

In 1957, the Program Evaluation and Review Technique (PERT) approach was created by the United States Department of Defense (DoD) and described organizing tasks into product-oriented categories. However, they did not use the term “work breakdown structure” or WBS until 1962 when DoD, NASA and the aerospace industry published a document about PERT that described the WBS approach.

Meanwhile, in 1960, Tom Gilb described his Evolutionary Value Delivery approach (or Evo for short) that is widely accepted to be a forerunner of agile approaches. Evo contains principles such as:

  • 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

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 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 here. For more articles from Mike Griffiths check his blog]




At the end of the day, at one time only one small amount of activity can be done. If anything worthwhile is to be achieved, what is needed is, small activities which build upon outcome of previous activity. For any activity to be proper input to next activity, it has to be completed with a definite useful outcome!

The efficiency of this chain depends on how effectively each activity is defined by way of input-process-output for specific duration.

Input can be everything, resource, skill and defined outcome. Process can be simple action of moving a hand and output can be tangible or intangible things which wil be input for next activity!

Tejal Shah

Coming from traditional PM background I really appreciate the comparison.thank you!

Rich Maltzman

First of all, thanks for this outstanding post, it really summarizes not only the WBS in a strikingly understandable way, it also links it to agile techniques in a way I hadn't seen before.

I teach these concepts and agree that the WBS standard seems to speak in self-contradictory terms. In my view, the WBS exists to capture scope. It is a brainstorming technique, which results in a visual representation of scope - a picture of cattle rather than a narrative about why you may want to slow down because you are approaching an area where there may be cattle.

To me that means one should avoid possible restrictions (and/or distractions) in brainstorming by thinking about "first we do this, then we do that" while brainstorming. I'm pretty insistent on this in my class exercises on the WBS. NO SEQUENCING! So I am glad that the standard at least generally sticks to this principle. Why they then talk about iterations and timing... well, that's a mystery to me as well.

I'm going to continue to be a brainstorming purist when it comes to the WBS and ask that students hold on to their time-oriented creativity until after we identify all of the work in the project.

That said, I'm also for progressive elaboration - so if a new work item DOES show up when you are now moving on to scheduling, by all means go back and revise the WBS (or whatever form of cattle sign you choose)!

Thanks again for the post, I really enjoyed it!

Rich Maltzman, PMP
Senior Lecturer, Boston University

Mike Griffiths

Manish, Tejal and Rich - Thanks for your comments, I appreciate you reading my article and taking the time to leave your thoughts.



Awesome, I really love it and thanks alot for coming up with PMI-ACP Prep guide which helped me in clearing the exam and more importantly gained sound knowledge on Agile practices.


I enjoyed the article however I need to disagree with the comments about iterations.

According to the definition, iteration a repetition of a process. In the case of the WBS the iteration should be considered deliverables as each repetition of the process should deliver new value. A downfall to this approach however is that this method does make determining scope creep much more difficult and why I prefer using epics, features, and stories to blend the methods together.

Iterations have nothing to do with time. They can be 2 weeks, hours or months depending on what the project decides. They also do not need to be the same as an iteration could have repetition completed much more quickly than a previous one based on the amount of work.

Did I help solve the puzzle?

Chimena Ijeh

Thanks Mike for your thought leadership approach on this topic. This is very expository and educative.
I have had such discussion on WBS and product backlog at some point in an interview and I could see the expression when I tried to use the WBS to describe a product backlog. So, I think it’s extremely helpful having this article.
However, I am quite confused on iteration a part of WBS element. Perhaps, they had a different context in mind and it’s worth elaborating.
Thanks again for your post, I really enjoyed reading it.

Scott Freauf

You mention PMI's WBS Practice Standard, which includes a set of core characteristics that must be present in every WBS. Here's three of those ---
- Contains work packages that clearly support the identification of the tasks that must be performed in order to deliver the work package
- Contains elements that are defined using nouns and adjectives—not verbs
- Arranges all major and minor deliverables in a hierarchical structure
Work packages are primarily defined by a "deliverable"...They are not defined by a "task"

Graeme Morgan

IMHO : For the sake of being able to update the standard and include Agile, I think the use of the word "iteration" is being applied a noun - defined as "the repetition of a process", thus time is not being represented.

Mike Griffiths

Scott/Graeme thanks for your comments. I agree that these may be reasons for the inclusion of iterations. When things settle down I will contact the contributors and ask them.
Best regards


Great article!
I'm using WBS structure to create SCRUM backlog since I learned SCRUM. My trainer used timelines to visualize backlog.

I have "Scrum Masters" at my work who are saying that "It can't be like that and you are wrong" and because of that, I liked the article a lot.

The comments to this entry are closed.