Work Breakdown Structure (WBS): How to Break a Project Into Tasks

A work breakdown structure, or WBS, is a tree of everything a project has to deliver. The top is the finished project. The next level is the handful of deliverables that make it up. Each deliverable splits into smaller pieces until every piece at the bottom, called a work package, is small enough for one person to own and finish. Two rules keep it useful: break it down by what gets delivered, not by department or phase, and make the pieces add up to 100% of the work, nothing missing and nothing extra. For a small team the bottom row is your task list. Below: the parts, the 100% rule, a worked example, a template, and how to paste the leaves onto a board.

What a work breakdown structure is

NASA’s Work Breakdown Structure Handbook↗ (opens in a new tab) calls a WBS “a product-oriented family tree” of the hardware, software, services and other deliverables a project needs, and says its purpose is to split the work into manageable pieces for planning and control. It adds a line that small teams should take to heart: work not contained in the WBS should not be considered part of the project. If it is not on the tree, nobody has agreed to do it.

• Level 1: the project, as one finished result. “Online booking is live.”
• Level 2: the major deliverables. Booking page, payments, notifications, launch, and the project management that holds them together.
• Level 3 and below: smaller pieces of each deliverable, until the pieces are work packages.
• Work package: the lowest level. One piece of work, clearly separate from every other, owned by one person or group, with a definition of done.
• WBS dictionary: an optional short description of each element, so two people reading “payments” picture the same thing.

The NASA handbook’s description of a work package fits a small team almost word for word: it is a unit of work at the level where work is performed, clearly distinguished from all other work packages, and assigned to a single organizational element. Replace “organizational element” with “person” and you have a good task.

The 100% rule

The rule usually called the 100% rule says the WBS covers all of the project’s work, and each element’s children together cover all of that element, no more and no less. NASA’s 2010 edition of the handbook turns it into a checklist question, “Does the overall WBS structure include 100% of the project scope of work?”↗ (opens in a new tab), and notes that the answer should include enabling work such as project management. Three practical checks follow from it:

1. Nothing missing. For each element, ask: if every child is done, is the parent done? If not, a child is missing. Testing, content, data migration and the launch announcement are the usual gaps.
2. Nothing extra. Every leaf traces up to something the project promised. A leaf that serves no parent is scope creep, and it belongs in a later project.
3. Nothing counted twice. If two leaves describe the same work under different names, merge them, or two people will both do it, or each will assume the other is.

Break it down by deliverables, not departments

The most common mistake is a tree whose level 2 reads Design, Development, Testing. That is a list of phases and job titles, and the NASA handbook says as much: design, engineering and manufacturing are functions, not products, and a phase is a time frame, so none of them makes a good WBS element. NASA’s software engineering handbook makes the same point for software, in its page on work breakdown structures that include software↗ (opens in a new tab): a product-oriented WBS groups work activities by the product or service they support.

The test is simple. Name each element with a noun for something that will exist (“card payment at booking”) rather than a verb for an activity (“develop payments”). Design and testing still happen; they happen inside each deliverable.

A worked WBS example

A cleaning company wants customers to book and pay online. Five deliverables at level 2, then the work packages under each:

1 Online booking is live
  1.1 Booking page
      1.1.1 Service and time-slot picker for the three standard services
      1.1.2 Customer details form with ZIP code check for the service area
      1.1.3 Page works on phones
  1.2 Payments
      1.2.1 Payment provider account approved
      1.2.2 Card payment taken at booking
      1.2.3 Refund path for cancellations
  1.3 Notifications
      1.3.1 Confirmation email to the customer
      1.3.2 New-booking alert to the office
  1.4 Launch
      1.4.1 Ten test bookings with real cards
      1.4.2 Announcement email to existing customers
  1.5 Project management
      1.5.1 Weekly review and timeline updates

Run the 100% checks. If every leaf under 1.2 is done, can customers pay? Yes. Is sales tax handled? Not if the business charges it on cleaning, so a leaf such as 1.2.4 belongs there. Is anything here that nobody promised? Online rescheduling was suggested at kickoff and is deliberately absent: it is out of scope, and the project plan says so. Project management sits on the tree because it is real work that takes real time, which is exactly what the 100% rule asks for.

How deep to go

• Stop when one person can finish a leaf in a few days and everyone agrees on what done means. That is a work package for a small team.
• Do not break everything to the same depth. A well-understood deliverable might stop at level 2; an uncertain one might need level 4.
• If a leaf would take more than a couple of weeks, split it. If splitting gives pieces of an hour each, you went one level too far.
• Three or four levels is plenty for a project of a few people over a few months.

A WBS template to copy

1 [Project, as one finished result]
  1.1 [Deliverable: a noun for something that will exist]
      1.1.1 [Work package] | Owner: [name] | Done when: [check]
      1.1.2 [Work package] | Owner: [name] | Done when: [check]
  1.2 [Deliverable]
      1.2.1 [Work package] | Owner: [name] | Done when: [check]
  1.3 [Deliverable]
      1.3.1 [Work package] | Owner: [name] | Done when: [check]
  1.N Project management
      1.N.1 [Reviews, updates, reporting] | Owner: [lead]

Checks: every parent fully covered by its children? Anything not promised?
Anything counted twice? Every leaf has one owner and a done check?

The WBS sits between two other pages. The project plan template holds the goal, scope in and out, milestones and risks; the WBS turns the scope into pieces of work. The milestones and their dates go on a project timeline, and if the pieces are tightly sequenced, a Gantt chart puts them on a calendar.

Turning the leaves into tasks on a board

The work packages are the tasks. The levels above them are context: they tell you which deliverable a task serves. On a fenbs board, Add many takes a pasted list and makes one task per line, with a preview before anything is created. Start a line with feature:, enhancement: or bug: to set that task’s kind; a line without one takes the kind you chose for the batch. Three things to know before you paste a WBS:

• Flatten it first. An indented line under a bullet becomes that task’s note, not a task of its own, so a pasted nested outline would turn your work packages into notes. Paste the leaves as a flat list.
• Headings are labels. When the paste contains bullets, a heading line is treated as a section label and not made into a task, so a deliverable can stay as a heading above its leaves.
• Paste one deliverable at a time. Project, category, lane and priority are set once per batch, so set the category to the deliverable (“Payments”) and every task in that batch carries it. Filtering by category then shows one branch of the tree.

## 1.2 Payments
- feature: Payment provider account approved
  Owner: Tom. Done when the provider confirms the live account.
- feature: Card payment taken at booking
  Owner: Tom. Done when a real card payment confirms a booking.
- feature: Refund path for cancellations
  Owner: Sam. Done when a canceled booking refunds the card in full.
- feature: Sales tax on bookings where it applies
  Owner: Priya. Done when the receipt shows the tax line.

Each task then has a note for the problem, a plan for how it will be done, a test status with test notes for how it was checked, and an optional size from XS to XL. An XL is the board telling you the WBS stopped one level too early: split it. Tasks move through To Do, Next Up, In Progress and Completed, and History records who moved each one, whether a person or an AI assistant connected over MCP.

Be clear about the gaps. fenbs has no epics, no parent and child tasks, no due dates and no assignee field you can set, so the tree itself lives in your plan document, the owner goes in the note as above, and the deliverable is a category. Related tasks can be linked, which records that they belong together without blocking either one. For a small team that is usually enough: the WBS is a thinking tool you use once at the start and again when scope changes, and the board is where the work is tracked every day.