A Work Breakdown Structure (WBS) is a hierarchical decomposition of a project into smaller, manageable components. It answers the question “what needs to be done?” by breaking the project down from the top-level deliverable into progressively smaller pieces until each piece is small enough to estimate, assign, and track. The WBS is a foundational project planning tool used across waterfall, agile, and hybrid methodologies.

Work Breakdown Structure: Decomposing Projects into Manageable Pieces

How a WBS Works

A WBS is organized in levels:

Level 1: The project itself. Level 2: Major deliverables or phases. Level 3: Sub-deliverables or components. Level 4+: Work packages — the lowest-level items that can be estimated and assigned.

Example for a mobile app project:

1. Mobile App Launch
  1.1 User Authentication
    1.1.1 Login screen
    1.1.2 Registration flow
    1.1.3 Password reset
    1.1.4 Social login integration
  1.2 Core Features
    1.2.1 Dashboard
    1.2.2 Profile management
    1.2.3 Notification system
  1.3 Backend Infrastructure
    1.3.1 API development
    1.3.2 Database setup
    1.3.3 Hosting configuration
  1.4 Quality Assurance
    1.4.1 Test plan creation
    1.4.2 Automated testing
    1.4.3 User acceptance testing
  1.5 Deployment
    1.5.1 App store submission
    1.5.2 Production deployment
    1.5.3 Monitoring setup

The 100% Rule

The WBS must include 100% of the work defined by the project scope. Everything in the scope statement must appear somewhere in the WBS, and nothing outside the scope should appear. This rule ensures that the WBS is complete and that no work is accidentally omitted from planning.

Deliverable-Oriented vs. Phase-Oriented

Deliverable-Oriented WBS

Organized by what is produced. The Level 2 items are the project’s major deliverables. This approach works well for product development where the focus is on what the customer receives.

Phase-Oriented WBS

Organized by when work happens. The Level 2 items are project phases: Requirements, Design, Development, Testing, Deployment. This approach aligns with waterfall methodology and is common in construction and engineering.

Most agile teams prefer a deliverable-oriented WBS because it aligns with feature-based backlog management.

WBS and Agile

In agile projects, the WBS translates to the backlog hierarchy:

WBS Level	Agile Equivalent
Level 1	Product/Project
Level 2	Epic
Level 3	Feature/User Story
Level 4	Task/Subtask

The WBS is typically created during project scoping or release planning and then translated into epics and stories in the PM tool. The backlog is the living WBS that is refined each sprint.

Creating a WBS

Step 1: Start with Deliverables

List the major deliverables from the project scope. These become Level 2 items.

Step 2: Decompose Each Deliverable

For each deliverable, ask “what components make up this deliverable?” Continue decomposing until you reach work packages that meet these criteria:

• Estimable: The team can provide a realistic duration or effort estimate
• Assignable: A single person or small team can take ownership
• Observable: Progress is visible and completion is verifiable
• Sized appropriately: 8-80 hours of effort (the 8/80 rule) or 1-2 sprint’s worth of work for agile teams

Step 3: Verify Completeness

Walk through the WBS with the team and stakeholders. For each Level 2 item, ask “if we complete all the Level 3 items under this, is the deliverable truly complete?” The answer must be yes for the WBS to follow the 100% rule.

Step 4: Number and Document

Assign WBS numbers (1.1, 1.1.2, etc.) and document each work package with a brief description. This numbering system is used throughout the project for task tracking, dependency mapping, and status reporting.

WBS Pitfalls

Decomposing too deeply. Breaking a task into sub-tasks into sub-sub-tasks creates a WBS that is too granular to manage. Stop when work packages are small enough to estimate and track but large enough to represent meaningful progress.

Confusing the WBS with a schedule. The WBS defines what needs to be done, not when. Scheduling happens after the WBS is created by adding durations, dependencies, and resource assignments. The WBS feeds into the schedule but is not the schedule.

Missing non-obvious work. Project management activities, documentation, testing, deployment, and training are often omitted from the WBS because they are less visible than feature development. Ensure the WBS includes all work needed to deliver the project, not just the development work.

Creating the WBS alone. The project manager should facilitate WBS creation, but the team should contribute. Developers identify technical components the PM may miss. Designers identify UX work. QA identifies testing activities. Collaborative creation produces a more complete WBS.