Work Breakdown Structure
A work breakdown structure (WBS) is a hierarchical breakdown of everything a project will deliver — and, by definition, nothing it will not. The WBS is a scope boundary drawn as a tree: if a piece of work is not somewhere in it, it is not in the project. This page covers the 100% rule, the WBS dictionary, control accounts, the numbering scheme and how deep to decompose.
- Defined in
- PMBOK / PMI standard
- Core rule
- The 100% rule
- Work package
- 8–80 hours
A scope boundary, not a task list
A Work Breakdown Structure decomposes a project into progressively smaller pieces of deliverable work, ending in work packages small enough to estimate and assign. Most people meet it as "the project plan in a tree", which misses what it is actually for.
Its real function is to draw the edge of the project. Once the WBS is agreed, it is the answer to "is this in scope?" — the answer is yes if the work appears in the tree and no if it does not. That is what makes it a contract artefact rather than a planning convenience, and why changing it is a change request rather than an edit.
Three things it is not
It is not a schedule. There are no dates in a WBS and no sequence — nothing in the tree says which branch comes first. The schedule is built afterwards, from the activities derived from the work packages, and it is a separate document that changes far more often.
It is not an organisation chart. Branches are pieces of the product, not departments. A WBS whose second level reads "Backend team, Frontend team, QA team" has quietly become an org chart, and every deliverable that needs two of them now has no home.
And it is not a to-do list. The bottom of the tree is a work package — a bundle of work with a definable result — not the individual steps someone takes to produce it. Those steps belong to the person doing the work, and putting them in the WBS is how a scope artefact turns into a micro-managed schedule.
The 100% rule
One rule governs the whole structure: the children of any node must add up to exactly 100% of that node — no more, no less. Nothing extra sneaks in at a lower level, and nothing is quietly missing.
The rule has a twin that is usually left unstated: nodes at the same level must be mutually exclusive. The same piece of work may appear in exactly one place in the tree. Break that and the 100% rule still looks satisfied while the estimate rolled up from the bottom counts the same work twice — which is the most common way a WBS-based budget comes out wrong without anyone being able to point at the error.
Together the two rules are what make a WBS auditable. Read any branch and you can ask a single question — "does this list fully describe its parent, with no overlaps?" — and get a yes or no. Estimates then roll up the tree without double counting, and a gap in the tree is a gap you can see rather than one you discover in month four.
Decompose deliverables, not activities
This is the mistake that turns a WBS into a mess. Nodes should be nouns — things that will exist when the work is done — not verbs describing the doing of it.
Deliverable-oriented (correct)
- Authentication service
- Password reset flow
- Session storage
- Security test report
Activity-oriented (avoid)
- Design the auth
- Write the code
- Test it
- Fix bugs
The right-hand column looks reasonable and fails immediately. "Write the code" cannot be checked against the 100% rule, cannot be marked done unambiguously, and repeats identically under every branch — which means the tree tells you nothing you did not already know. Deliverables can be inspected; activities can only be reported on.
Three ways to organise the second level
The top node is the project. The second level is the one real decision, because everything below it inherits that choice. The PMI standard recognises three legitimate patterns, and mixing them at the same level is what produces trees nobody can navigate.
By major deliverable
Authentication, Catalogue, Checkout, Reporting. The default, and the right choice when the product has clearly separable parts that different people can own.
By project phase
Discovery, Design, Build, Migration, Handover. Suits work whose phases have genuinely different deliverables — a data migration, a certification, a physical rollout.
By subproject
Split by vendor, site or system when different organisations deliver different chunks. Each subproject then decomposes internally by its own logic.
Work packages, control accounts and the dictionary
The bottom level of a WBS is the work package. The common heuristic is the 8/80 rule: a work package should take no less than 8 hours and no more than 80. Below 8 hours you are managing minutiae; above 80 you cannot tell whether it is on track, because a status of "half done" on a three-week package is an opinion rather than a measurement.
| Level | Typical size | Who owns it |
|---|---|---|
| Project | months | Sponsor |
| Deliverable | weeks | Project manager |
| Sub-deliverable | days–weeks | Team lead |
| Work package | 8–80 h | One person or pair |
The WBS dictionary
A node in the tree is two or three words, which is nowhere near enough to hold a scope boundary. The WBS dictionary is the companion document that says, for each work package, what it actually includes and excludes, what its acceptance criteria are, who owns it, what it is estimated to cost and what it depends on. It is the part practitioners skip, and it is the part that settles the argument six months later about whether "Reporting" included exporting to PDF.
Control accounts and planning packages
A control account is a node — usually above the work packages — where scope, budget and actual cost are brought together and measured. It is the point at which someone answers "are we on budget for this part?". You do not need one per work package; you need one per piece of the project somebody is accountable for financially, which is typically far fewer.
A planning package is the honest placeholder for work that is inside a control account, known to be needed, and not yet decomposed. It carries a budget and no detail. Using them is what keeps the 100% rule true for a project whose later phases are genuinely not knowable yet — instead of inventing fake work packages to fill the gap.
The numbering scheme
Every node gets a code: 1, then 1.1, 1.1.2 and so on. This looks like decoration and is not. The code is the identifier that timesheets, purchase orders, risk entries and change requests all refer to, so cost actually collected in the field can be rolled back up the same tree the estimate came down. Once numbers are issued they are never reused — a deleted branch leaves a hole rather than being renumbered, because the old number is sitting in six months of invoices.
Not every branch needs the same depth. Decompose the risky and unfamiliar parts further than the routine ones — a branch you have delivered ten times before can stop at a coarser level without adding risk. Doing this deliberately over time is called rolling wave planning: the next few months are decomposed to work-package level, the rest sits as planning packages, and each cycle converts one wave into detail. A WBS built entirely at a uniform depth usually means someone filled in a template.
WBS in an agile world
A WBS assumes the full set of deliverables is knowable up front, which is exactly the assumption agile delivery declines to make. That does not make it obsolete — it makes it the wrong tool for a discovery-heavy product and the right one for a defined piece of work inside it.
| Aspect | WBS | Product Backlog |
|---|---|---|
| Shape | Tree, complete | Ordered list, open-ended |
| Completeness | 100% of scope, fixed | Emergent, never complete |
| Unit | Deliverable | Slice of user value |
| Ordering | None — the tree has no sequence | The whole point — the list is ranked |
| Changing it | A change request | Routine, every refinement |
The two are not rivals so much as answers to different questions. A backlog answers "what should we do next?" and is deliberately never finished. A WBS answers "what did we agree the whole of this is?" and is worthless unless it is complete. An organisation that needs both usually needs them for different pieces of work — not for the same one, where maintaining two views of the same scope guarantees they will disagree.
How this shows up in real delivery
The place a WBS earns its keep in an otherwise agile organisation is at the contract boundary — a fixed-scope integration, a migration with a defined target, a regulated deliverable. It gives the sponsor a scope they can sign and the team an unambiguous answer when someone asks for "just one more small thing".
Where it degrades
- Activity verbs instead of deliverable nouns, which makes the 100% rule uncheckable.
- The same work appearing under two branches, so estimates double count.
- A tree with no dictionary, which leaves every scope boundary to memory and goodwill.
- The second level organised by department, which turns the WBS into an org chart.
- Uniform depth everywhere, which is the signature of a filled-in template rather than analysis.
- Built once and never revisited, so it stops describing the project it was meant to bound.
When to use it
Use it when
- Scope is contractually fixed and someone must sign off exactly what is included.
- The deliverables are genuinely knowable in advance — a migration, an integration, a certification.
- Cost or effort must roll up reliably from the bottom without double counting.
- Work spans several teams or vendors and the boundaries between them need to be explicit.
- You are prepared to write the dictionary as well as draw the tree.
Avoid it when
- The product is in discovery and the deliverable list will change monthly.
- You already have an ordered product backlog — do not maintain both for the same work.
- It would be built to satisfy a process audit rather than to answer a real scope question.
- The team would decompose to task level, turning a scope artefact into a micro-managed schedule.
Found this useful?
Share it with someone who is working on the same problem.