The Work Breakdown Structure (WBS) is a powerful tool to help scope work at any level – when used properly. But it is usually mis-understood (everybody does work breakdowns, right?); and perhaps because it is listed in an outline format, many consider it a waterfall tool. See also: the Agile Deceit.

To avoid this, let's talk about it differently, as what it really is: A Deliverable Breakdown Structure (DBS).

A DBS can be worked in an Agile manner iteratively, scoping work only as needed.

A DBS is not:

a work breakdown!
an exhaustive list of work (but is instead a classification of project scope)
a project plan, a schedule, nor a chronological listing (waterfall / gantt charts).

It specifies the individual components to make a resulting product. It is not the “how” something is to be done, but rather than “what” for a need. Nor is it the “when.”

Rules:

Focus on Outcomes not Actions - not tasks, but rather deliverable products or outcomes. I.e. a bike is made up of wheels, a frame, etc. everything required to produce the outcome (see examples below).
100% Rule - all work for a parent deliverable must be encompassed by child elements; and there is no overlap between elements (mutually exclusive). This can be confusing where you have work across sections - see examples below.
Level of Detail - decide when to stop decomposing work based on estimated work. i.e. “1 week” or “20 hours” etc.
Estimate just enough - A DBS adds an Agile consideration to the WBS Level of Detail Rule: which is to stop decomposing work when you are confident of the effort below a leaf of the hierarchy.

You also use a hierarchical coding scheme (usually 1.1.1.. type hierarchy).

The terminal element is the lowest level, this is where you focus on resourcing (turn these into stories/tasks).

Breaking the mold

In an Agile software development world the WBS is also often misunderstood if not simply discarded for being "too waterfall," largely due to a lack of understanding of the distinction between a task or a deliverable. Or it is simply dismissed because the speaker doesn’t fully understood how a WBS really works.

Another problem is in the name itself. Everybody does "work breakdowns" as part of their regular life routine. But a "work breakdown" and a "Work Breakdown Structure" are two distinctly different things, with the latter having a formal set of principles that govern how it works.

For these reasons, I instead call it a Deliverable Breakdown Structure (DBS).

As counterintuitive as it may feel, I guarantee that a little effort spent adding a DBS into your process will reduce the time you spend in analysis paralysis, it will make your estimates incredibly more accurate, and it will give you a DNA that your project can lean against to keep on pace with where you are trying to go.

In my experience, software engineers who do a proper DBS on something they are struggling to scope invariably come out with a better estimation and greater confidence; but ironically, at the same time the resulting DBS is often frustrating for project managers, if they look at it as a list of tasks!

To understand the value, take some time to try a few DBS exercises. Study what makes a good DBS at the last section.

Greater Detail

Outcomes not Actions

Plan outcomes (deliverables / products) not actions! Write nouns, not adjectives. I.e.

Wing

Not:

Assemble the Wing system

This may feel like it is nit-picking, but it is extremely critical in helping to orient the mind. In the first example, to have a finished wing one must consider all the possible sub elements of the wing, such as landing gear. But in the second example it is easy to assume that the landing gear will just be available, the "task" is now scoped simply to the assembly.

100% Rule & Mutually Exclusive

All work to make a deliverable is encompassed underneath that deliverable. If you find a desire to state that to complete one item, another somewhere else in the hierarchy must be finished, then you need to reorganize your hierarchy. This is a very common problem when doing a work breakdown from a feature perspective, and not a formal DBS.

Furthermore, there should be no duplication across hierarchies. If, to make the wing, one must make a hydraulic system to drive the flaps, but in the tail system you must also create a hydraulic system... the hydraulic system may be better moved upwards in the hierarchy. Otherwise, you might create incompatible systems and duplicate work efforts. This is mutually exclusive

Level of Detail

The WBS is commonly considered part of the defined/waterfall project management process because it is such a valuable tool and came into its own decades ago and has become widely used in the defined/waterfall system. But a DBS is merely a tool, not a part of the defined/waterfall system, and the Level of Detail principle clearly defines this.

Estimate Just Enough

Stop decomposing a component if you are confident of the estimate, and it isn't needed in the near-term iteration. Leaving items as TBD is acceptable in different leafs of the hierarchy.

Or considered differently, the Level of Detail only needs to be broken down to the level necessary for the work being done in the next work interval(s), and to verify you have thought about the work effort enough to scope it to your needs. This is a very vague statement, but what it is saying is that you do not need to fully analyze the entire system. Just analyze enough of it to meet your needs, and then you should stop.

In an Agile world, I suggest doing a high level DBS for the overall effort, and then on a regular interval (perhaps monthly) pick different areas and refine them to help you know what to do next.

Examples

100% Rule

Not Idiomatic

1. Airplane

1.1. Wings

1.1.1. Flaps

1.1.1.1. Hydraulic System

1.1.2. Fuselage

1.2. Cockpit

1.3. Tail

1.3.1. Hydraulic System

1.4. Factory

Idiomatic

1. Airplane

1.1. Wings

1.1.1. Flaps

1.1.2. Fuselage

1.2. Cockpit

1.3. Tail

1.4. Hydraulic System

1.5. Factory

Outcomes not Actions

Not Idiomatic

This shows a common “work break down” where it is task oriented. It tends to miss things.

1. The Software Widget Feature

1.1. Build Servers

1.1.1. Re-use Devzone

1.1.2. Create new Prodzone cluster

1.3. Design Frontend

1.3. Create Frontend

1.4. Fix Backend Problems

1.4.1. Resolve Legacy Transaction Problem

1.4.2. Revise Ledgers

1.5. Stress Test

Idiomatic

By focusing on outcomes and products, it helps one recognize other elements of the process, such as the design and planning pieces, and even things one wouldn’t usually think of, like software delivery. It is okay to leave some elements as TBD, subject to the outcome of other elements. The WBS is be a living thing.

1. The Software Widget Feature

1.1. Scalable Platform

1.1.1. Architecture/Design of Platform

1.1.2. Stress Test Results

1.1.3. Delivery / Deployment System (not even identified above)

1.1.4. Devzone (TBD from 1.2.1)

1.1.5. Prodzone (TBD from 1.2.1)

1.2. Frontend Module

1.2.1. UX Designs for Frontend

1.2.2. Code Module Changes (TBD from 1.3.1)

1.3. Backend

1.3.1. Functional Transaction System

1.3.1.1. Architecture/Design Transaction System v2

1.3.1.2. Transaction Modules v2 (TBD from 1.4.1.1)

1.3.2. Ledger v2

1.3.2.1. Architecture/Design Ledger v2

1.3.2.2. Ledger Modules v2 (TBD from 1.4.2.1)