WBS and Agile Were Never at War
Kickoff meeting with the client. Their PMO says: "We'll need monthly milestones and WBS-based progress reporting." Back at the office, the dev lead says: "We run Scrum. Isn't a WBS a waterfall relic?"
The PM stands between them. The contract and the reporting demand a WBS; the team runs on sprints. Many PMs resolve this by deceiving one side: secretly maintaining a WBS the team never sees, or dressing up the sprint board as a WBS for the client. Either way, it's double bookkeeping. And double bookkeeping always gets caught.
The frame is wrong
"WBS or Agile?" is itself a category error. They are not competitors — they are tools of different dimensions.
A WBS is the decomposition of What: the totality of what this project must deliver, structured with no gaps and no overlaps (the 100% Rule from Part 1). A WBS says nothing about how you work.
Agile is the execution of How: a method for building an agreed scope in what rhythm, with what feedback loops. A sprint is a way of working, not a structure of scope.
"WBS is a waterfall relic" confuses What with How. The PMBOK 7th edition, in fact, defines life cycles as a spectrum from predictive to adaptive and tells you to tailor to your context. Pure waterfall and pure agile are just the two endpoints; most real-world contract-based projects live somewhere in between — in hybrid.
Hybrid, in practice
Here is the structure that satisfies both sides without double books.
Fix the top two or three levels as a WBS. Deliverables, major milestones, and contract-level scope are structured as a tree and baselined (Part 3). This layer is your commitment to the client and executives, and it is under change control. It moves slowly.
Delegate the inside of each work package to the team. How "Settlement module (120h)" gets built — how many stories, which sprints — is decided by the team's backlog. This layer moves fast and is not exposed in client reporting.
Connect the two layers with a single progress rule. When a story belonging to a work package reaches Done in a sprint, that completion rolls up as the work package's progress (the event-based crediting from Part 4 working again). The team speaks in story points; the client hears milestones and SPI. Two languages for the same facts — but one ledger.
As a table, the structure looks like this. The key insight: the work package is the hinge between the two worlds.
| Layer | PM world (WBS) | Team world (Backlog) | Who controls it |
|---|---|---|---|
| Levels 1–2 | Deliverables, phases | (maps to Epics) | PM — baseline & change control |
| Level 3 | Work Package | Feature / story cluster | The boundary — they meet here |
| Below | (don't descend) | Stories, tasks, sprint assignment | Team — backlog refinement |
Progress flows bottom-up: Story Done → work package progress (EV earned) → milestone & SPI roll-up → client report. The team never needs to look up; the client never needs to look down.
Running Agile inside a contract
To "can we be agile under a fixed contract?", answer with three separations:
- Fixed scope, variable detail: scope at the work-package level is fixed by contract and baseline; how it's built — story decomposition, implementation approach — the team adjusts every sprint
- Fixed milestones, free iterations: verification points with the client are promised as dates; how many sprints fill the gaps is the team's call
- Changes via CR, improvements via refinement: demands that cross a work package boundary go through change control (Part 3); adjustments within the boundary are backlog refinement. When this distinction collapses, scope starts leaking under the banner of "well, we're agile"
Keep two messages ready. To the dev team: "The WBS doesn't dictate how you work. It records what we promised — inside the sprint, the work belongs entirely to you." To the client: "Sprints are our internal execution unit. Reporting is based on approved deliverables and milestones."
Tools recreate the problem
The structure is clean; the reason it collapses in practice is that tools support only one worldview. Sprint tools have no WBS, baselines, or EVM; traditional PM tools have no backlog or sprints. So the PM ends up hand-building bridges between two tools — and regresses straight into the double-bookkeeping problem of Part 2. This is why, when we designed our own PM tool, we made hybrid the default assumption rather than a separate mode: WBS and baselines on top, the team's execution rhythm below — one data model that speaks both languages.
What sets WBS and Agile against each other is tooling and inertia, not principle. Holding the map of What while granting the freedom of How — the hybrid-era PM's job is to use both hands at once.
The PM's action block
Three things to do tomorrow
- Explicitly designate the work-package level in your WBS as "the boundary delegated to the team"
- Map the backlog's epics/stories to work packages — any unmappable story is a scope issue in disguise
- Agree with the team on one rule: how does Story Done roll up into work package progress?
Questions to ask in the next meeting
- "Which work package does this story belong to? If none — why are we doing it?"
- "Is this client request inside or outside the work package boundary?" (inside → refinement; outside → CR)
- "Do any client-facing milestone dates collide with the sprint calendar?"
Good signs / bad signs
| Good signs | Bad signs |
|---|---|
| Every story has a work package as its parent | The backlog and the WBS have never met |
| Scope requests auto-sort into CR vs. refinement | "We're agile" is used to justify scope changes |
| The team sees sprints; the client sees milestones | Client reports are hand-assembled every week |
What a tool should solve
The root of double bookkeeping was two tools, each supporting one worldview. That's why, in designing wbsgantt, we made hybrid the default assumption rather than a separate mode — WBS, baselines, and EVM on top; the team's execution units attach beneath each work package; Done events roll up automatically. With one ledger, you may still need translation — but never double entry.