The plain-English guide
The work breakdown structure
Before a plan can have a shape, the work has to have pieces. The WBS is the splitting step — the outline you write before any chart can draw a single bar. Here's how to build one, and where to stop.
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.
It's the least glamorous step in planning and the one that saves the most projects. Not because the numbered outline is clever — it isn't — but because walking a project top-down is how you find the work everyone forgot. The WBS comes before the schedule: it hands its leaves to the critical path, which puts them in order, and to the Gantt chart, which draws them over time. No breakdown, nothing to draw.
Split the work
One project, broken down
The same six-week bakery-website launch the rest of the cluster uses. 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 top into the few big chunks the work naturally falls into — design, content, build, launch. These aren't tasks yet; they're the drawers you'll sort the real work into. Keep it to a handful, and let each one end at a milestone you could point at.
- 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 the moment a piece is small enough to give an honest duration and hand to one owner. Go finer than that and you're writing a to-do list, not a plan — the checklist inside a task belongs to whoever owns it, not on the chart.
- 05
Walk it once for what's missing
Read the whole tree top-down and ask the only question that matters: is anything missing? This is the pass that catches "migrate the DNS" and "write the release notes" — the unglamorous work that sinks timelines precisely because nobody wrote it down. Find it here, before the schedule does.
Once the tasks exist, the next move is putting them in order. See where the breakdown fits in the whole plan →
Why the boring step is the one that saves you
It's a completeness check
A plan doesn't usually blow up on the task everyone could see coming. It blows up on "migrate the DNS," "get legal to sign off," "write the release notes" — the unglamorous work that never made it onto anyone's list. The WBS exists to catch exactly that, before the calendar does.
That's what the tree structure buys you. Because the pieces under any branch are supposed to add up to all of that branch — the 100% rule — walking it top-down turns "did we think of everything?" from a vibe into a checkable question. Under a branch that doesn't sum, there's either forgotten work or smuggled-in scope.
The other half of the discipline is knowing when to stop. Split until each leaf is estimable and ownable, then quit — the old 8/80 rule (nothing smaller than a day, nothing bigger than two weeks) is a decent fence. Go finer and you've stopped planning and started writing someone else's to-do list; the checklist inside a task belongs to its owner, not to the chart.
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.
Skip the tree, keep the thinking
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 →