What it is, what it isn't
A WBS is deliverable-oriented. Each node is a thing you'll produce, not a task you'll do. "Patient Handoff Module — UI" is a WBS node; "design the UI" is not. Tasks come from decomposing each leaf during scheduling.
The 100% rule
PMI's WBS Practice Standard: each level of the WBS must contain 100% of the work — no more, no less. If you decompose a parent into children, those children together must equal the parent. This sounds obvious until you're three levels deep and someone tries to add a thing that doesn't ladder up.
↳ the work-package rule
Decompose until each leaf — a work package — is small enough that one person or pair can own it for a sensible duration. Common heuristic: 8–80 hours of work, or the famous "two week" rule.
Hierarchy example
| Level | Item |
|---|---|
| 1.0 | Patient Handoff Module |
| 1.1 | UI |
| 1.1.1 | Login screen |
| 1.1.2 | Handoff list view |
| 1.2 | API |
| 1.2.1 | Auth endpoints |
| 1.2.2 | Handoff CRUD endpoints |
| 1.3 | Database migration |
| 1.4 | Compliance + sign-off |
↳ in the wild
The WBS feels like overhead until the project hits week 8 and someone asks, "wait, who owns the migration script?" The team that has a WBS knows in 30 seconds. The team without one spends a meeting figuring it out.