/ Leadership

Powerful Agile WBS

Work Breakdown Structure (WBS) is a powerful tool to help scope work at any level – when used properly. It can be worked in an agile manner iteratively, scoping work only as needed.

A WBS 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).

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.”


  • 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. You can have different LOD’s for different leafs of the hierarchy, as needed to be agile.

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).

Example - 100% Rule

Not Idiomatic

  1. Airplane
    1.1. Wings
    1.1.1. Flaps Hydraulic System
    1.2. Fuselage
    1.2.1. Cockpit
    1.2.2. Tail Hydraulic System
    1.3 Factory


  1. Airplane
    1.1. Wings
    1.1.1. Flaps
    1.2. Fuselage
    1.2.1. Cockpit
    1.2.2. Tail
    1.3. Hydraulic System
    1.4. Factory

Example - 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


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 Architecture/Design Transaction System v2 Transaction Modules v2 <TBD from>
    1.3.2. Ledger v2 Architecture/Design Ledger v2 Ledger Modules v2 <TBD from>
Brandon Gillespie

Brandon Gillespie

Brandon loves Tech and has a breadth of experience including hands-on Implementation and Leadership Roles across many companies including small startups, enterprises, and the USAF.

Read More