Work Breakdown Structure (WBS): The 100% Rule, a Template, and a Full Example

Quick answer: A work breakdown structure breaks a project into smaller and smaller pieces until each piece is small enough to assign, estimate and track. It lists deliverables, not activities. The key rule is that every level must add up to 100% of the level above it, with nothing extra and nothing missing.

A big project is impossible to plan. A hundred small pieces of a project are easy to plan.

That’s the whole idea. You take “build a new conference” and keep splitting it until you reach things like “book the caterer” — something one person can own, estimate and finish.

This guide covers the real rules, including the one most guides state and never explain: how to actually check that your breakdown is complete. You’ll also get a template, a WBS dictionary, and a full worked sample with codes and costs that add up.

What Is a Work Breakdown Structure?

A work breakdown structure, usually shortened to WBS, is a chart that breaks a project down into smaller parts, level by level, until each part is small enough to manage.

The critical detail: a WBS lists things, not actions.

This is a deliverable	This is an activity
Registration platform	Set up the registration platform
Catering	Order the food
Session materials	Design the slides
AV and sound	Hire the microphones

The left column belongs in a WBS. The right column belongs in your schedule, which comes afterwards.

This trips up almost everyone the first time. If your WBS entries start with verbs, you’ve written a task list instead.

A simple way to picture it

Think about making a birthday party happen.

You wouldn’t write “do the party.” You’d break it down: the cake, the invitations, the decorations, the games, the party bags. Then you’d break the cake down further: the ingredients, the baking, the icing.

Each level is still the whole party, just described in more detail. That’s a WBS.

Where it comes from

The method is set out in the Project Management Institute’s Practice Standard for Work Breakdown Structures, now in its third edition. If you’re studying for a PM qualification, that’s the source your exam is based on.

WBS vs OBS vs RBS vs CBS vs PBS: What Is the Difference?

Project management loves a breakdown structure, and the acronyms collide. Here’s what each one actually splits up.

Acronym	Full name	What it breaks down
WBS	Work breakdown structure	The work and deliverables
OBS	Organisational breakdown structure	The teams and departments doing the work
RBS	Resource breakdown structure	The people, equipment and materials
RBS	Risk breakdown structure	The categories of risk — same acronym, different thing
CBS	Cost breakdown structure	The budget
PBS	Product breakdown structure	The physical parts of the product, not the work

Two warnings worth knowing:

RBS means two different things. Resource breakdown structure and risk breakdown structure share the acronym. Always check which one someone means — several published guides use both on the same page without saying so.

PBS is not a WBS. A product breakdown structure lists the components of the thing. A WBS lists the work needed to produce it, which includes work with no physical output, like project management and testing.

What Is the 100% Rule, and How Do You Check It?

The 100% rule is the most important principle in a WBS. It says two things:

1. Nothing missing. The WBS must include all the work in the project scope.
2. Nothing extra. It must include no work that’s outside the scope.

And the practical version: the children must add up to the parent. Every level must total 100% of the level above it.

Everyone states this rule. Almost nobody tells you how to check it. Here are three ways that actually work.

Check 1: the cost roll-up

Give every work package a cost. Add them up within each branch. Does each branch total match the figure for the level above? Does the top level match your project budget?

If the sums don’t reconcile, you’ve either missed work or double-counted it. This is the fastest and most objective check there is, and the worked sample later on this page shows it in action.

Check 2: the “where does this live?” test

Take ten things you know the project needs — a test plan, a sign-off meeting, a training session, the final report. For each one, ask: which work package does this belong to?

If you can’t point to one, you’ve found a gap.

Check 3: the reverse read

Read the WBS bottom-up. Start at a work package and ask: does this belong in the project at all?

Anything you can’t justify is scope creep that has already crept in, before any work has started.

A rule people forget: project management itself is work, so it needs a place in the WBS. So do testing, training, documentation and closure. These are the pieces most commonly left out, and they’re the ones that always cost money anyway.

What Are the Parts of a WBS?

Part	What it is
Level 1	The whole project — one box at the top
Level 2	The major deliverables or work streams, often called control accounts
Level 3+	Sub-deliverables, broken down further as needed
Work package	The lowest level of any branch — the smallest piece you manage
WBS code	The numbering that identifies each element
WBS dictionary	A companion document describing each element in detail

What is a work package?

A work package is the lowest item in a branch. It’s the smallest piece of work you plan, assign, estimate and track.

A good work package has four properties:

• One owner. A single named person is accountable, even if several people do the work.
• Estimable. You can put a realistic duration and cost on it.
• A clear finish. You can tell when it’s done without arguing.
• Independent enough. It doesn’t overlap confusingly with another package.

What is a control account?

A control account is a point in the WBS — usually level 2 — where you track cost and progress as a group, rather than package by package.

The simple difference: a work package is what you assign; a control account is what you report on.

On a small project you can ignore control accounts entirely and report at level 2 informally. On a large one, they’re how you keep the reporting manageable when there are 300 work packages.

Deliverable-Based vs Phase-Based: Which Should You Use?

Every guide lists the types. Few tell you how to pick. Here’s the actual decision.

	Deliverable-based	Phase-based
Level 2 contains	The things you’re producing	The project’s phases
Example level 2	Venue, Programme, Marketing, Production	Initiate, Design, Build, Test, Launch
Best when	The project has distinct, separable outputs	The project runs one output through sequential stages
Advantage	Clear ownership per deliverable	Matches a stage-gated process neatly
Risk	Phase work like testing can get scattered	The same deliverable appears in several phases, splitting ownership

How to choose, in one question

Could two different people own two different level-2 branches at the same time?

• Yes → use deliverable-based. The conference example works this way: one person can run the venue while another runs the programme.
• No, the work has to happen in order → use phase-based. A waterfall project with hard phase gates often fits this better.

Deliverable-based is the more common choice and the one PMI’s standard leans toward, because ownership is cleaner. Use phase-based when your organisation’s reporting is built around phases and fighting that would cost you more than it gains.

A hybrid also works. Deliverable-based at level 2, with phases inside a branch where the work genuinely is sequential.

How Do You Build a WBS? Eight Steps

Step 1: Start from the scope, not from a blank page

Pull out your project scope and project charter. The WBS is a decomposition of an agreed scope. Building one before the scope is agreed means decomposing a guess.

Step 2: Write the project at level 1

One box. The project name. That’s it.

Step 3: Identify your level-2 branches

Four to seven branches is the sweet spot for most projects. Fewer and each one is too big to be meaningful; more and the chart becomes unreadable.

Use the question above to decide whether these are deliverables or phases.

Step 4: Decompose each branch

Take one branch at a time and break it down. Keep asking: what are the parts of this?

Don’t try to keep the levels symmetrical. One branch might need four levels while another needs two. That’s normal — depth should follow complexity, not tidiness.

Step 5: Stop when each piece passes the work-package test

The next section covers exactly when to stop.

Step 6: Number everything

Apply your coding scheme as you go, not afterwards. Renumbering a finished WBS is miserable.

Step 7: Check the 100% rule

Run the three checks above. Fix what they find.

Step 8: Write the WBS dictionary

Then get the whole thing reviewed by the people who’ll do the work. They will find things you missed, every time.

How Far Should You Decompose? When to Stop

Going too deep is as damaging as not going deep enough. A WBS with 400 work packages on a three-month project is a tracking burden nobody will maintain.

The 8/80 rule

The most common guideline: a work package should take between 8 and 80 hours of effort — roughly one day to two weeks.

Smaller than a day, and you’re managing minutiae. Bigger than two weeks, and problems can hide inside it for too long before anyone notices.

Treat it as a guide, not a law. Long projects sometimes work fine with larger packages.

Four better tests

The 8/80 rule is a rough filter. These four tell you more:

Test	Stop decomposing when…
Owner test	One named person can own it
Estimate test	You can estimate cost and duration with reasonable confidence
Done test	You can state clearly what “finished” looks like
Status test	You could report progress on it without guessing a percentage

The status test is the most useful. If someone has to say “about 60% done” with no evidence, the package is too big.

How many levels?

Three to five for most projects. Three for something small, five for something large or heavily regulated.

If you’re going past six, check you haven’t started listing activities instead of deliverables.

How Do You Number a WBS?

A coding scheme lets you refer to any element precisely. The standard approach is nested decimals:

1.0        Annual User Conference
1.1        Venue and Catering
1.1.1      Venue selection and contract
1.1.2      Room hire
1.2        Programme and Speakers
1.2.1      Programme design

Three rules:

1. Never reuse a code. If you delete a work package, retire its number. Don’t reassign it.
2. Leave gaps if you expect additions. Numbering in tens (1.10, 1.20, 1.30) lets you insert later without renumbering.
3. Use the code everywhere. In the schedule, the budget, the risk register, the change requests. The code is what connects your documents together.

That last point is the real payoff. When a change request says “this affects 1.4.2,” anyone can find it in any document.

What Goes in the WBS Template?

Copy this structure and fill it in.

WORK BREAKDOWN STRUCTURE

Project:
Project manager:               Date:
WBS version:                   Scope baseline reference:
Structure type: deliverable-based / phase-based / hybrid

LEVEL 1
1.0  [Project name]

LEVEL 2 — control accounts / major deliverables
1.1  [Deliverable]            Owner:          Budget:
1.2  [Deliverable]            Owner:          Budget:
1.3  [Deliverable]            Owner:          Budget:
1.4  [Deliverable]            Owner:          Budget:
1.5  Project management       Owner:          Budget:

LEVEL 3 — work packages
| WBS code | Work package | Owner | Effort (hrs) | Duration | Cost |
| 1.1.1    |              |       |              |          |      |
| 1.1.2    |              |       |              |          |      |

100% RULE CHECK
Sum of level 3 within each branch = level 2 figure?       ☐
Sum of level 2 = total project budget?                    ☐
Project management included?                              ☐
Testing / quality work included?                          ☐
Training and documentation included?                      ☐
Closure activities included?                              ☐
Nothing present that is outside the agreed scope?         ☐

Reviewed by:                   Date:
Approved by:                   Date:

What Is a WBS Dictionary?

The WBS dictionary is a companion document that describes each element properly. The chart gives you a name; the dictionary gives you the detail.

Most guides mention it in one sentence and move on. It’s the document that stops people interpreting “Catering” six different ways.

WBS dictionary template

One entry per work package.

WBS DICTIONARY ENTRY

WBS code:
Work package name:
Control account:
Owner:
Description of work:
Deliverables / output:
Acceptance criteria:
Assumptions:
Exclusions (what this package does NOT cover):
Predecessors:
Effort estimate:            Duration:
Cost estimate:
Resources required:
Risks:

The two fields that earn their place are acceptance criteria and exclusions. Together they stop the two most common arguments on any project: “that isn’t finished” and “I thought you were doing that.”

A sample dictionary entry

WBS code:            1.1.3
Work package name:   Catering
Control account:     1.1 Venue and Catering
Owner:               Leila M., Events Coordinator

Description of work:
Select and contract a caterer. Agree menus for both days,
including dietary requirements. Manage delivery and service
on site across the two event days.

Deliverables:
Signed catering contract; agreed menu document; dietary
requirements list; service plan for both days.

Acceptance criteria:
Catering served on schedule across both days. All recorded
dietary requirements met. No more than 10% food waste.

Assumptions:
Final attendee numbers confirmed 14 days before the event.
Venue permits external caterers.

Exclusions:
Speaker dinner on the evening before (covered in 1.2.3).
Bar and alcohol service (not in scope).

Predecessors:   1.1.1 Venue selection and contract
Effort:         40 hours        Duration: across 10 weeks
Cost:           £18,000
Resources:      Events Coordinator; external caterer
Risks:          Late attendee numbers; dietary data incomplete

Notice the exclusion. Without it, the speaker dinner gets booked twice or not at all.

A Full Work Breakdown Structure Sample

Here’s a complete work breakdown structure sample with codes, owners and costs that reconcile.

Project: Annual user conference · 300 attendees · 2 days · Budget £120,000

Level 1 and 2

WBS code	Element	Owner	Budget
1.0	Annual User Conference	Priya M. (PM)	£120,000
1.1	Venue and Catering	Leila M.	£48,000
1.2	Programme and Speakers	Dan K.	£22,000
1.3	Marketing and Registration	Sana R.	£18,000
1.4	Production and AV	Tomas B.	£20,000
1.5	Project Management	Priya M.	£12,000

Level 3 — the 19 work packages

1.1 Venue and Catering — £48,000

Code	Work package	Effort	Cost
1.1.1	Venue selection and contract	30 hrs	£2,000
1.1.2	Room hire, two days	10 hrs	£26,000
1.1.3	Catering	40 hrs	£18,000
1.1.4	Accessibility arrangements	20 hrs	£2,000

1.2 Programme and Speakers — £22,000

Code	Work package	Effort	Cost
1.2.1	Programme design	40 hrs	£3,000
1.2.2	Speaker recruitment	60 hrs	£4,000
1.2.3	Speaker travel, fees and dinner	30 hrs	£13,000
1.2.4	Session materials	50 hrs	£2,000

1.3 Marketing and Registration — £18,000

Code	Work package	Effort	Cost
1.3.1	Brand and campaign assets	50 hrs	£5,000
1.3.2	Email and social campaign	70 hrs	£4,000
1.3.3	Registration platform	40 hrs	£6,000
1.3.4	Attendee communications	30 hrs	£3,000

1.4 Production and AV — £20,000

Code	Work package	Effort	Cost
1.4.1	Stage and set	25 hrs	£7,000
1.4.2	AV and sound	30 hrs	£8,000
1.4.3	Live streaming	35 hrs	£4,000
1.4.4	Recording and edit	40 hrs	£1,000

1.5 Project Management — £12,000

Code	Work package	Effort	Cost
1.5.1	Planning and coordination	120 hrs	£7,000
1.5.2	Risk and contingency management	25 hrs	£1,000
1.5.3	Post-event review and closure	60 hrs	£4,000

The 100% rule check, done properly

This is the part the competing guides skip. Add up each branch:

Branch	Work packages sum to	Level 2 figure	Match?
1.1	2,000 + 26,000 + 18,000 + 2,000 = £48,000	£48,000	Yes
1.2	3,000 + 4,000 + 13,000 + 2,000 = £22,000	£22,000	Yes
1.3	5,000 + 4,000 + 6,000 + 3,000 = £18,000	£18,000	Yes
1.4	7,000 + 8,000 + 4,000 + 1,000 = £20,000	£20,000	Yes
1.5	7,000 + 1,000 + 4,000 = £12,000	£12,000	Yes
Total	48,000 + 22,000 + 18,000 + 20,000 + 12,000 = £120,000	£120,000	Yes

Every branch reconciles and the total matches the budget. The 100% rule is satisfied, and you can prove it rather than assert it.

Two things worth noticing about this sample:

• 1.5 Project Management is in the WBS. It’s real work with a real cost. Leaving it out is the most common 100% rule failure.
• 1.4.4 Recording and edit costs £1,000 but takes 40 hours. Cost and effort aren’t the same thing. Room hire is the reverse — £26,000 for 10 hours of admin. Don’t use cost as a proxy for how much work something is.

What Happens After the WBS?

The WBS isn’t the plan. It’s the thing you build the plan from. Four documents come out of it:

Next step	What the WBS gives you
Schedule	The work packages become the tasks you sequence and date
Budget	The cost roll-up becomes your cost baseline
Scope baseline	The WBS, the dictionary and the scope statement together
Responsibility matrix	Each work package gets an owner, which becomes your RACI

The schedule step is the big one. Each work package becomes one or more activities, and those activities get durations and dependencies. Our guide to project planning and scheduling picks up from there.

Later, when something changes, the WBS code is what your change control process refers to.

How Does a WBS Work for Software and Agile Projects?

The principle holds. The vocabulary changes.

For software projects run in phases, a WBS works exactly as described. Level 2 might be the modules or components; work packages are features or build items.

For agile projects, there’s a natural equivalent:

Traditional WBS	Agile equivalent
Level 1 project	Product or release
Level 2 deliverables	Epics or feature areas
Work packages	User stories
WBS dictionary	Acceptance criteria on each story

The genuine difference is when you decompose. A traditional WBS is built up front. An agile backlog is decomposed progressively — near-term work broken into stories, later work left as epics until it’s closer.

That’s called rolling-wave planning, and it’s compatible with a WBS rather than opposed to it. Decompose the next few months to work-package level and leave the rest at level 2. Our guide to agile task management planning goes further.

One thing that doesn’t change: the 100% rule. If the work isn’t in the backlog, nobody is doing it.

Best Software Tools to Create a Work Breakdown Structure

Four different jobs, four different kinds of tool.

Job	What to look for	Type of tool
Drawing the tree diagram	Shapes, auto-layout, easy export to image	Diagramming tools
Managing the WBS as data	Indented hierarchy, custom fields, roll-up sums	Spreadsheets, or project tools with outline views
Linking the WBS to a schedule	WBS codes, dependencies, baselines, critical path	Scheduling tools
Writing the dictionary	Templates, version history, shared editing	Document tools and AI writing assistants

Five features that actually matter

• Automatic roll-up. If the tool sums child costs into the parent, your 100% rule check is continuous rather than manual.
• A WBS code field. Without one, you’re typing codes into a text column and they drift.
• Outline or indent view. A tree diagram looks good in a presentation; an indented list is what you actually work in.
• Baselines. So you can see how the WBS changed after approval.
• Export. Someone will ask for it in Excel. Always.

An honest recommendation

For most projects, a spreadsheet with four columns — code, work package, owner, cost — and a SUM formula per branch does the job better than specialist software. The roll-up check is a formula, and everyone can open it.

Move to a scheduling tool when you need dependencies and a critical path, not before. Buy the tool for the problem you have.

Step-by-Step Guide to Building a Work Breakdown Structure in Popular Project Software

Menu names change, so check your tool’s help pages if a step looks different. The approach is the same everywhere.

In a spreadsheet (Excel or Google Sheets)

1. Create columns: WBS Code, Element, Level, Owner, Effort, Cost.
2. Enter level 1 in row 1, then your level-2 branches.
3. Indent level 3 rows visually, and set the Level column to 3.
4. Add a SUM formula under each branch totalling its work packages.
5. Add a formula comparing each branch total to its level-2 figure. Flag any mismatch.
6. Freeze the header row and filter by Level to collapse the view.

This is the fastest route, and the roll-up check is built in.

In Microsoft Project

1. Enter your level-1 task, then level-2 tasks beneath it.
2. Use the indent button to demote tasks — Project builds the hierarchy from indentation.
3. Turn on the WBS column so codes generate automatically.
4. Enter costs at work-package level; Project rolls them up to summary tasks.
5. Save a baseline once the WBS is approved.

In a task-board tool (Asana, Monday.com, ClickUp)

1. Create a project per level-1, and a section or parent task per level-2 branch.
2. Add work packages as tasks or subtasks under each.
3. Add custom fields for WBS Code, Owner, Effort and Cost.
4. Use a roll-up or formula field if the tool offers one, so costs total upward.
5. Save it as a template for the next project.

In Jira

1. Create an epic per level-2 branch.
2. Add stories or tasks under each as work packages.
3. Use a custom field for the WBS code.
4. Keep the dictionary in the connected wiki, linked from each epic.

In a diagramming tool (Lucidchart, Miro, draw.io)

1. Start from a hierarchy or org-chart template.
2. Build top-down, one box per element, labelled with code and name.
3. Export as an image for your plan and presentations.
4. Keep the data version in a spreadsheet — a diagram alone can’t do the roll-up check.

The rule across all of them: the diagram is for communicating. The data version is for working. Keep both, and keep the spreadsheet as the master.

What Are the 8 Most Common WBS Mistakes?

1. Listing activities instead of deliverables. If your entries start with verbs, it’s a task list.
2. Leaving out project management. It’s real work with real cost. It needs a branch.
3. Forgetting testing, training, documentation and closure. The four most commonly missed, and they always cost money anyway.
4. Decomposing too far. 400 work packages on a short project is a tracking burden nobody maintains.
5. Forcing symmetry. Branches don’t need equal depth. Complexity should decide.
6. Never checking the 100% rule. Stating the rule isn’t the same as applying it. Do the cost roll-up.
7. Skipping the dictionary. Then “Catering” means six different things to six people.
8. Building it alone. The people doing the work will find your gaps. Let them.

How Does Writegenic AI Fit In?

A WBS itself is a structure, and a spreadsheet handles that well. What takes the time is everything written around it — and that’s where Writegenic AI helps.

You can use it to:

• Draft the WBS dictionary, one entry per work package, from your notes
• Write acceptance criteria and exclusions for each package in consistent language
• Turn the WBS into a scope baseline document for sign-off
• Draft the responsibility matrix from the owner column
• Write the status report that rolls the branches up for your sponsor
• Produce a first-pass breakdown from a scope statement, as a starting point to challenge

It fits alongside the other documents in the set: the project charter, the scope management plan, the schedule, and the closure report.

Explore AI for project management or use the prompt generator for sharper instructions.

Draft with the tool, keep the judgement. AI can produce a plausible breakdown in seconds. It cannot know which deliverables your client actually agreed to, who on your team can own what, or what your real costs are. A WBS that looks right but doesn’t match the agreed scope is worse than no WBS — it makes a scope problem look solved. Check it against the scope statement yourself, then have the team review it.

Try Writegenic AI free

Frequently Asked Questions

Related reading:

• Project Planning and Scheduling: Steps + Example
• Creating a Scope Management Plan: A Step-by-Step Guide
• Project Charter Templates With Real Examples
• Configuration Management Plan: Template + Example
• Project Closure: Checklist + Closure Report Template