What is a Work Breakdown Structure (WBS)?

How a WBS is Structured

A WBS has hierarchical levels, each one breaking the level above into more specific components:

• Level 1: Project — the final deliverable (e.g., 'New company website')
• Level 2: Major phases or deliverables (e.g., 'Discovery', 'Design', 'Development', 'Launch')
• Level 3: Work packages (e.g., 'Create wireframes', 'Design homepage', 'Build contact form')
• Level 4+: Tasks and subtasks (e.g., 'Desktop wireframe', 'Mobile wireframe', 'Wireframe review with client')

The 100% Rule: The Core WBS Principle

The most important WBS rule: the sum of all child components must equal 100% of the parent. Nothing is missing; nothing is double-counted.

If your WBS has phases Discovery, Design, and Development, those three phases must account for 100% of the project work. If there's work that doesn't fit any of them (like a client onboarding process), it needs its own category.

The 100% rule prevents two failure modes: missing work (tasks that nobody planned for) and double-counting (the same work appearing in two branches, getting estimated twice).

WBS vs Task List vs Project Plan

These three tools are related but distinct:

A task list is flat — a sequential list of things to do. Simple but doesn't show structure or hierarchy.

A WBS is hierarchical — shows how components relate to each other and how they roll up to the final deliverable. It's a scope document, not a schedule.

A project plan (or schedule) adds time to the WBS — when each task starts, how long it takes, and when it ends. A Gantt chart is a common format for the project plan.

The WBS comes first, then the schedule. You can't plan when things happen until you know what all the things are.

WBS for a Website Redesign: Full Example

A concrete WBS example makes the concept easier to apply. Here's a Level 1-3 WBS for a typical 10-week agency website redesign project. Level 1 is the project. Level 2 is major phases. Level 3 is work packages within each phase.

Each work package at Level 3 should be estimable (you can put an hour count on it), assignable (one person owns it), and trackable (you can mark it done).

WBS Dictionary: What It Is and When You Need It

A WBS dictionary is a companion document to the WBS that defines each work package in detail. Where the WBS shows structure and hierarchy, the WBS dictionary explains what each item actually means — who's responsible, what done looks like, how long it should take, what the acceptance criteria are.

For a simple 20-work-package project, the WBS dictionary might be a table with five columns per row. For a complex 100-work-package project, each entry might be a half-page description.

You need a WBS dictionary when work package titles alone are ambiguous. 'Design homepage' means different things to different people. Does it include mobile design? Multiple concepts? With or without copy?

For agencies, the WBS dictionary also serves as a basis for scope validation with clients. When the client reviews and approves it, both sides have agreed on exactly what each deliverable includes. A revision request for something outside the defined scope is then unambiguously a change request.

• WBS shows structure; WBS dictionary explains what each work package actually means
• Include: responsible party, acceptance criteria, hour estimate, key assumptions
• Use when work package titles are ambiguous or the team hasn't done this work before
• Client approval of the WBS dictionary creates a defensible scope boundary

WBS in Agile Projects

Agile teams sometimes treat the WBS as a waterfall artifact. That's a mistake. The WBS concept — decomposing scope into manageable, estimable chunks — is just as useful in Agile; it just looks different.

In a Scrum project, the product backlog is functionally equivalent to a WBS. Epics are Level 2. User stories are Level 3. Sub-tasks are Level 4. The hierarchy exists; it's just built iteratively rather than all at once at the start.

The key difference: a traditional WBS is built for the full project upfront. An Agile WBS (backlog) is built progressively — the near-term items (next 2 sprints) are detailed; the distant items are rough epics that will be refined when they're closer to being scheduled.

The 100% rule still applies in Agile: all backlog items together must represent 100% of the project scope. Items added to the backlog that weren't in the original scope are scope changes.

• Product backlog = Agile WBS: Epics (L2), Stories (L3), Sub-tasks (L4)
• Traditional WBS: full scope defined upfront. Agile WBS: near-term detailed, far-term rough
• Fixed-price Agile: build a high-level WBS to anchor the quote, refine sprint by sprint
• The 100% rule applies — all backlog items must cover 100% of contracted scope