The plain-English guide
The work breakdown structure
A work breakdown structure divides a project into manageable pieces. Build the outline before estimating durations and setting dates, so you can check that the schedule includes all the work.
From the studio behind ganttchart.ai · a 6-minute read
A work breakdown structure is a project cut into pieces small enough to plan. You take the whole thing, split it into a few phases, and split those into tasks — stopping the moment each piece is small enough that one person can own it and honestly guess how long it takes. The result is a tree, and its leaves are the tasks everything else is built from.
Reviewing the outline helps you find missing work before setting dates. Once the tasks are defined, you can map their dependencies, calculate the critical path, and draw the Gantt chart to show the schedule over time.
Split the work
One project, broken down
This is the six-week bakery-website example used throughout these guides. The project splits into four phases; the highlighted leaves are the 5 tasks small enough to estimate — the ones that become bars on the chart.
- 1 Bakery website launch
- 1.1 Design — wireframes + visual design, signed off 2w
- 1.2 Content
- 1.2.1 Copy — pages written & edited 2w
- 1.2.2 Photos — shoot + retouch 2w
- 1.3 Build — front-end, wired to the CMS 3w
- 1.4 Launch
- 1.4.1 QA & fixes — test, patch, re-test 1w
- 1.4.2 Go live — the deliverable is handed over
Notice what the branches don't carry: no durations, no dates. Only the leaves get estimated — the headings above them just prove the pieces add up. Hand those five leaves to the critical path method and the six-week finish falls out.
The breakdown, in five moves
How to build one
No software required, and no numbering unless you want it. The whole method is splitting the work until the pieces are small enough to plan — and knowing when to stop.
- 01
Start from the finished thing
Put the whole project at the top of the tree, named as a deliverable — the thing that exists when you're done, not the effort. "Bakery website, live." Everything below has to add up to exactly that, nothing more.
- 02
Break it into phases
Split the project into phases such as design, content, build, and launch. Use these headings to group the tasks, and mark the end of each phase with a milestone where useful.
- 03
Split each phase into tasks
Keep dividing until each leaf is a real task — one someone could own, and finish in a sitting or a week. "Content" becomes "Copy" and "Photos." The leaves are the only rows that carry work; the branches above them are just headings.
- 04
Stop at the estimable line
Stop splitting when a piece is small enough for one owner to estimate its duration. The owner can keep a separate checklist for the details within that task.
- 05
Walk it once for what's missing
Review each branch for missing work. Include tasks such as DNS migration and release notes if they are needed to deliver the project. Check that each branch covers its full share of the scope.
Once the tasks exist, the next move is putting them in order. See where the breakdown fits in the whole plan →
Check for missing work
It's a completeness check
Tasks such as migrating DNS, getting legal approval, or writing release notes are easy to overlook. Reviewing each branch of the WBS helps you find those omissions before estimating the schedule.
The pieces under each branch should cover all the work in that branch. This 100% rule gives you a way to check for omissions and work outside the agreed scope.
Stop splitting when one person can estimate and take responsibility for the task. The 8/80 rule (nothing smaller than a day, nothing bigger than two weeks) is one rule of thumb. Leave the detailed checklist within each task to its owner.
Common questions
The WBS, briefly
What is a work breakdown structure, in one sentence?
A work breakdown structure (WBS) is the outline you write before a plan can have a shape: you take the whole project and split it into phases, and phases into tasks, until every piece is small enough that someone can name it, own it, and estimate how long it takes. Those smallest pieces — the leaves of the tree — are the tasks your schedule and critical path are built from.
What's the difference between a WBS and a to-do list?
A to-do list is flat and personal — the next actions for one person. A WBS is a tree and it covers the whole project: it shows how every task rolls up into a phase and every phase into the deliverable, so you can check that the pieces add up to the goal with nothing missing and nothing extra. The rule of thumb: a WBS stops where a to-do list starts. Once a piece is small enough for one owner to estimate, the checklist inside it is their to-do list, and it doesn't belong on the chart.
How detailed should a work breakdown structure be?
Only as detailed as it takes to estimate and assign each piece — no finer. The old rule of thumb is "8/80": a leaf task shouldn't be smaller than about 8 hours or bigger than about 80 (roughly a day to two weeks). Too coarse and the plan hides the work; too fine and you're maintaining a diary. Stop splitting the moment a piece is something one owner could pick up and give an honest duration for.
What is the 100% rule?
The 100% rule says the children of any node must add up to exactly that node — all of it, and nothing outside it. So the tasks under "Content" have to cover everything content means for this project and nothing else. It's what makes the WBS a completeness check rather than a wish list: if the leaves under a branch don't sum to the branch, either you've forgotten work (under 100%) or you've smuggled in scope that doesn't belong (over 100%).
Do I have to number it 1.0, 1.1, 1.2?
No. The numbering (1.0, 1.1, 1.1.1…) is just an address system so people can refer to a task without ambiguity, and it's genuinely useful on a large program with hundreds of tasks. For a normal-sized project the thinking is what matters, not the notation: the indented outline you'd write to describe the plan is a work breakdown structure whether or not you number it.
What comes after the WBS?
Order and time. The WBS gives you the tasks; the next moves are putting them in order (which task waits on which — the dependencies) and estimating each one, which together let you trace the critical path and draw the Gantt chart. In other words the WBS is step two of planning a project — the raw material the schedule is built from. Describe those tasks to ganttchart.ai and it does the ordering and drawing for you.
Every term above is defined, jargon-free, in the plain-English glossary.
Turn the task list into a chart
Once you can list the tasks, you're most of the way there. Describe them to ganttchart.ai in a sentence or two and it orders them, draws the plan over time, and highlights the critical path — so the breakdown you did by hand turns straight into a chart.
Try ganttchart.ai →