The Work Breakdown Structure

Deliverables, not activities, at the upper levels. Name the upper elements with nouns: "SRS", "Application", "Deployment". A WBS is a breakdown of what is produced, not a list of how it is produced; the how comes in the schedule. Work packages may be phrased as things to produce, "the use case diagram", or as outcomes, "unit tests passing".

Mutually exclusive. A piece of work appears in exactly one place. If the database schema appears under both Design and Application, it will be estimated twice or, worse, done twice.

Small enough, and no smaller. A work package should be small enough that one person can estimate it with confidence and finish it without losing track. Many project managers keep work packages between about a day and two weeks of effort. A student team working a few hours a week scales that down: a work package of between two and twenty hours is about right. Anything bigger hides uncertainty; anything smaller turns the plan into a to-do list.

One owner each. Every work package has one person answerable for it. Others may help.

The WBS dictionary

A diagram shows the structure but not the detail. The WBS dictionary is a table that says, for each work package, what exactly it is:

The "done when" field is the most useful and the most often left empty. "SRS written" is not a criterion; "SRS v1.0 reviewed with the owner, changes made, and approved by the guide" is.

Three ways to draw it

A top-down chart, the classic picture: the project in a box at the top, deliverables in a row beneath it, work packages hanging below each. Clear on paper, and very wide.

A sideways tree: the project on the left, deliverables in a column to its right, work packages to their right. It shows the same structure and stays narrow however many deliverables there are, which suits a report and a phone screen alike.

An outline, numbered and indented, usually as a table with the estimates beside each work package. The least pretty, and the easiest to add up and to keep up to date.

A good WBS document has a picture and an outline: the picture to understand it, the outline to use it.

The worked project: the WBS

The worked team drew its WBS as a sideways tree, in PlantUML, and kept the source in its repository so that anyone could change it and draw it again:

Figure 16.1 The worked team's work breakdown structure: seven deliverables and twenty-eight work packages

This is the source of that figure:

@startmindmap wbs
* Canteen\nPre-order
** 1 Management
*** 1.1 Proposal
*** 1.2 Plan
*** 1.3 Reviews
** 2 Requirements
*** 2.1 Survey
*** 2.2 Interviews
*** 2.3 SRS
** 3 Design
*** 3.1 UML set
*** 3.2 Schema
*** 3.3 API
*** 3.4 Wireframes
*** 3.5 Architecture
** 4 Application
*** 4.1 Frontend
*** 4.2 Backend
*** 4.3 Database
*** 4.4 Security
*** 4.5 Errors
*** 4.6 Reviews
** 5 Testing
*** 5.1 Unit
*** 5.2 Integration
*** 5.3 System
*** 5.4 Load, security
** 6 Deployment
*** 6.1 Local
*** 6.2 Server
*** 6.3 APK
*** 6.4 GitHub
** 7 Documents
*** 7.1 Report
*** 7.2 Manual
*** 7.3 Presentation
@endmindmap

The source uses PlantUML's mind map form, whose branches grow sideways. PlantUML also has a form made for WBS charts, which starts with @startwbs and draws the classic top-down chart; the team tried it first, and with seven deliverables it came out nearly three times as wide as it is tall, too wide for their report's pages.

The outline, with estimates

Hours are person-hours of effort. Module 1's deliverables come first, then Module 2's, each module totalling the 120 hours that four students at MU's 30 hours each have for it.

The two modules together are 240 hours, which is exactly four students at 60 hours each: the 100 per cent rule applied to time. If the work packages had added up to 300, the plan would have been promising work nobody had hours for.

Meetings are work

The team's first outline had no hours for its own stand-ups, which Chapter 15 set at fifteen minutes every Tuesday. That is seven meetings in Module 1 and six in Module 2, and four people at each. With the reviews held with the guide and the owner, meetings come to 12 hours in each module, a tenth of its time. Time spent is part of the work whether or not anyone plans it, so the 100 per cent rule put the meetings in the WBS, as 1.3 and 4.6. The hours came from trimming other estimates, never from adding hours nobody had.

Checking it against Chapter 13

In Chapter 13 the team estimated 64 hours to build and test the seventeen functional requirements. In the WBS those features live in five work packages: frontend 18, backend 16, database 10, authentication and validation 12, and unit tests 8, which add up to 64. The two estimates agree because they were made together.

The rest of Module 2's hours are work no single requirement owns: error handling across the whole application, the reviews and stand-ups, integration, system, load and security testing, deployment and the documents. This is the work students leave out when they estimate from the feature list alone, and the reason their plans run out of time.

The Could Haves of Chapter 13 have no work package on purpose. They are contingency: built only if other work finishes early, which in the event it did not.

An extract of the WBS dictionary

Do this for your project

1. Put the project at the top and MU's deliverables beneath it: proposal, requirements, design, application, testing, deployment, documents.
2. Break each down until every piece can be estimated, owned by one person and recognised as finished.
3. Check the 100 per cent rule: nothing missing (meetings, reviews, testing, deployment), nothing counted twice, nothing out of scope.
4. Number every element and never reuse a number.
5. Estimate every work package in hours; check that the total fits your team's hours.
6. Write the WBS dictionary, with a real "done when" for each work package.
7. Draw it in a form that fits your report, and keep the outline for daily use.

Mistakes that cost marks

A WBS of activities. "Coding", "Testing", "Meeting" at the top level is a to-do list with no structure of deliverables.

Forgotten work. No meetings, no reviews, no testing, no deployment, no documents: the most common gaps, all caught by the 100 per cent rule.

A WBS that does not add up. Estimates totalling far more than the team's hours are a plan that cannot happen.

Work packages with no owner, or with "all" as the owner, which in practice means nobody.

"Done when" left empty, so nothing can ever be shown to be finished.

Quick revision

• A WBS is a deliverable-oriented, hierarchical breakdown of all the project's work.
• The bottom level is the work package: estimated, owned by one person, recognisable as done.
• The 100 per cent rule: the WBS holds all the scope's work and nothing else; parts add up to their parent.
• Upper levels are deliverables (nouns); elements are numbered (2, 2.3, 2.3.1); each piece of work appears once.
• The WBS dictionary gives each work package a description, deliverable, done when, owner, estimate and dependencies.
• The WBS feeds the estimate, the schedule, the resource plan, progress tracking and risk.

Questions you must be able to answer

1. What is a work breakdown structure, and what is a work package? A hierarchical breakdown of the whole scope of a project into deliverables and smaller components. The work package is its lowest level: a piece of work small enough to be estimated with confidence, assigned to one person, scheduled, and recognised as finished.

2. State the 100 per cent rule and explain what it catches. The WBS must include all the work in the project's scope and no work outside it, so that at every level the parts add up exactly to their parent. It catches forgotten work such as testing, reviews and deployment, work counted twice, and work that is not in scope.

3. Why are the upper levels of a WBS named with nouns? Because a WBS breaks down what the project produces, its deliverables, rather than the activities that produce them; the sequence of activities belongs in the schedule.

4. What is a WBS dictionary, and which field matters most? A table describing each work package: its description, deliverable, completion criterion, owner, estimate and dependencies. The completion criterion, "done when", matters most, because without it nothing can be shown to be finished.

5. How did the worked team check that its WBS was realistic? Its work packages add up to 240 person-hours, exactly four students at 60 hours each, and its feature work packages add up to 64 hours, the same figure as its estimate for the functional requirements in Chapter 13.