Every work breakdown structure eventually stops branching. The point where it stops is the work package, and what happens there decides whether the WBS is a real control tool or just a pretty diagram nobody manages against.

A work package isn't a task on a to-do list. It's a control concept: the lowest level at which a project estimates cost, assigns a single owner, and measures progress against a plan. Get that level wrong, sized too big, too small, or missing an owner, and every plan built on it (the schedule, the budget, the earned value report) inherits the mistake.

Key Facts

By the U.S. Department of Defense's own earned value glossary, a work package is "the point at which work is planned, progress is measured, and earned value is computed," while its parent control account is the actual management control point, defined as where budgets and actual costs are compared to earned value for management purposes.

Level of Effort work packages, the kind with no discrete, measurable output, should generally run no longer than 12 months, per PMI's published guidance on planning packages.

A planning package "must be converted to Work Packages prior to any charges being incurred for the effort," the same PMI guidance states, the rule that keeps far-term budget lines from quietly absorbing real spend before anyone has planned the work.

Percent complete is one of the most widely used progress measurement methods for a work package, but NASA's own EVM reference guide requires it to be backed by Quantifiable Backup Data to stay an objective measurement rather than a guess.

Our own work breakdown structure guide already sets the sizing heuristic this page builds on: no work package smaller than 8 hours or larger than 80 hours of effort, a rule of thumb rather than a standard.

What is a work package?

A work package is the lowest level of a work breakdown structure at which work is planned, estimated, assigned to a single owner, and tracked to completion. It sits below a deliverable or sub-deliverable and represents scope small enough that one person, or one team, can complete it with a known effort, output, and acceptance test.

That definition matters, because most confusion around work packages comes from treating the term as a synonym for "a chunk of work" rather than a specific control concept. A work package isn't defined by size alone. It's defined by what happens at that level: cost gets estimated there, progress gets measured there, and a schedule activity list gets built from it. The Department of Defense's own earned value glossary is precise about this, describing a work package as the "natural subdivision of Control Accounts," the exact point at which work is planned, progress is measured, and earned value is computed.

That's also why a work package is a control concept, not a to-do item. A to-do item exists so someone remembers to do something. A work package exists so a project can answer three questions at any point: how much of this scope is done, who is accountable for it, and how much it has cost against what it was supposed to cost. Nothing above the work package (a deliverable, a phase, the project itself) answers those questions directly. Everything above it answers them by rolling work packages up.

Work package vs deliverable vs activity vs task vs milestone

This is the confusion that sends most people looking for this page in the first place, and it's worth being exact about it, because the five terms answer genuinely different questions.

Term	What it actually is	Who or what "owns" it	Example
Deliverable	A specific output someone hands off and someone else formally accepts	A named approver, per project deliverables	The approved office floor plan
Work package	The lowest-level chunk of scope with one owner, an estimate, and a verifiable output	One individual or one team	Furniture procurement and delivery
Activity (schedule activity)	A scheduled unit of effort with a start date, an end date, and dependencies	Whoever is assigned in the project schedule	"Order furniture," "Confirm delivery window"
Task	The smallest unit of individual effort, often below what a schedule even tracks	One person, for a short duration	"Call the vendor to confirm the delivery truck size"
Milestone	A zero-duration marker on the schedule, usually the moment something else finishes	Nobody produces a milestone directly; it just gets hit	"Furniture delivered, October 3"

The line that trips up almost everyone: a work package is not itself a schedule activity. A work package gets decomposed into one or more schedule activities during planning, the same way a deliverable gets decomposed into work packages during WBS construction. "Furniture procurement and delivery" is a work package. "Send RFQ to three vendors" and "Confirm delivery window" are the schedule activities that make it up. Mixing the two levels is how a Gantt chart ends up with hundreds of line items and no clear sense of who owns what at the level that actually matters for cost and accountability.

Control account, planning package, and work package: the hierarchy

A work package doesn't sit in isolation. It's one of two possible children of a control account, and that hierarchy is what makes far-term planning honest instead of guesswork dressed up as detail.

Level	What it is	Detail	Charges allowed?
Control account	The management control point, where a scope statement, a schedule, and a time-phased budget are integrated and compared to earned value	Aggregates one or more work packages and planning packages beneath it	N/A, it's the reporting level, not a charge point itself
Work package	A discrete, scheduled piece of scope with one owner and a known measurement method	Fully decomposed to the activity level	Yes
Planning package	Known future work within a control account that hasn't been detail-planned yet	A budget total and a target date, no task list	No, not until it converts

The Department of Defense's EVM glossary defines a control account as the point where "budgets (resource plans) and actual costs are accumulated and compared to earned value for management control purposes," and a planning package as future work that "cannot yet be detail planned at the Work Package or task level." A PMI paper on using planning packages puts the rule on that gap in plain terms: a planning package "must be converted to Work Packages prior to any charges being incurred for the effort." You can budget against a placeholder. You cannot spend against one.

This is exactly the mechanism rolling wave planning is built on. Near-term work gets decomposed into real work packages, because it's understood well enough to plan in detail. Far-term work stays a planning package, a budget and a milestone, until its wave arrives and earns a full decomposition. The control account holds both pieces together, giving a sponsor one honest number for the whole account even while half of it stays coarse by design.

The WBS dictionary entry, field by field

A work package without a dictionary entry is a label with no substance behind it. Our work breakdown structure guide already establishes the baseline fields: description, owner, estimated effort, required inputs, deliverable criteria, and dependencies. A work package entry goes a step further, because it's the level where someone actually has to execute against the entry, not just read it.

Field	What it captures	Why it matters at the work package level
WBS code	The unique identifier locating this package in the hierarchy (e.g., 1.2.3.1)	Ties the package to its parent deliverable and control account for reporting
Description	A short, unambiguous statement of the work	Should read as a noun phrase, an output, not a verb
Owner	The single accountable individual or team	One name, never "team" or "TBD"
Estimated effort	Hours or days, sized within the project's chosen range	Feeds the schedule, the cost baseline, and resource assignment
Charge code	The cost account or project code actuals get booked against	Lets accounting tie real spend back to this exact package
Required inputs	What must exist before work can start (approvals, prior deliverables, access)	Surfaces dependencies before they become blockers
Acceptance criteria	The specific, testable condition that makes the output acceptable	Separates "the team thinks it's done" from "the owner accepted it"
Assumptions and exclusions	What the estimate assumes to be true, and what is explicitly not included	Protects the estimate from silently absorbing extra scope
Resource requirements	Named people, skills, tools, or materials needed	Feeds resource allocation and staffing decisions
Quality requirements	The standard the output must meet beyond "it exists"	Prevents a technically complete package from being unusable
Dependencies	Predecessor and successor work packages	Feeds the network diagram and the critical path

Here's what a filled-in entry looks like for the office relocation example used later in this guide:

Field	Value
WBS code	1.2.1
Description	New-office workstation furniture, procured and delivered
Owner	Facilities Coordinator
Estimated effort	32 hours
Charge code	REL-2026-FAC-12
Required inputs	Approved floor plan, signed vendor quote
Acceptance criteria	All workstations delivered, undamaged, matching the approved floor plan count and layout
Assumptions and exclusions	Assumes standard lead time from vendor; excludes ergonomic accessories, which are a separate package
Resource requirements	Facilities Coordinator, approved vendor, loading dock access
Quality requirements	Furniture matches approved spec sheet; no visible damage on delivery
Dependencies	Predecessor: floor plan approval. Successor: workstation setup and network testing

Notice how much of the entry exists to prevent a specific, predictable argument later. The assumptions line stops a dispute about accessories. The acceptance criteria stop a dispute about what "delivered" means. The charge code stops a dispute about whether this package's actual cost belongs here or somewhere else.

Sizing a work package: the 8/80 rule and beyond

The 8/80 rule, as our work breakdown structure guide states it, is a sizing heuristic: no work package should run under 8 hours or over 80 hours of effort. Repeating the caveat that guide already makes, because it gets lost constantly: 8/80 is a rule of thumb, not a standard issued by PMI or any standards body. Some organizations run 4/40 for short, fast-moving efforts, or stretch to 160 hours on multi-year programs. The number changes. The reasoning behind it doesn't, and it holds regardless of which hour range an organization picks.

Framing	The actual question it answers
Completable within one reporting period	Can this package's status change meaningfully between two consecutive status checks, rather than sitting "in progress" for months unchanged?
Estimable with confidence	Is the scope understood well enough that the estimate is a real number, not a guess wearing a number's clothes?
One accountable owner	Can exactly one person or team be held responsible for the output, without needing to split credit or blame?
A verifiable output	Is there something specific enough at the end that someone else can inspect it and say yes or no?

A package that fails any one of these four tests is sized wrong, independent of its hour count. A 40-hour package with three people quietly sharing it fails the ownership test even though it sits inside 8/80. A 6-hour package that can't be estimated with confidence, because nobody actually knows what it involves yet, fails the estimability test regardless of how small it looks. Use the hour range as a first-pass filter; use these four questions as the actual test.

A worked example: office relocation

Abstract sizing rules make more sense against a real decomposition. Here's an office relocation broken down to the work-package level, the same project used in the WBS dictionary example above.

WBS code	Work package	Owner	Effort (hrs)	Acceptance criteria
1.1.1	Floor plan design	Facilities Coordinator	24	Floor plan approved in writing by department heads and facilities lead
1.1.2	Vendor selection and contracting	Procurement Lead	40	Signed contract with moving vendor and furniture supplier, within approved budget
1.2.1	New-office furniture procurement and delivery	Facilities Coordinator	32	All furniture delivered undamaged, matching approved floor plan count
1.2.2	IT infrastructure move	IT Lead	56	All workstations and network equipment relocated and powered on at new site
1.3.1	Workstation and desk setup	Facilities Coordinator	48	Every assigned desk matches the floor plan, cabling routed and labeled
1.3.2	Network and systems testing	IT Lead	24	All test users confirm network, phone, and printer access from their assigned desk
1.4.1	Old office decommission	Facilities Coordinator	16	Old site cleared, keys returned, final walkthrough signed off by landlord
1.4.2	Address change notifications	Operations Coordinator	8	All vendors, clients, and regulatory bodies confirmed updated on new address

Two things worth noticing. First, every effort figure sits inside a defensible range: none is a single afternoon's task, none runs past two working weeks. Second, every acceptance criterion is something a third party could check without asking the owner "so, is it done?" That's the difference between a work package and a line item someone typed in because the WBS needed one more row.

What a work package feeds downstream

A work package isn't the end of the planning chain. It's the input to almost everything that comes after scope definition.

Downstream artifact	What the work package contributes
Schedule activities and the network diagram	The work package gets decomposed into scheduled activities with durations and dependencies, which the network diagram then sequences
Cost baseline	The work package's estimated effort and rate become a line in the cost estimation rollup
Resource assignment	The named resource requirements in the dictionary entry drive resource allocation decisions
Responsibility assignment (RACI)	The work package's single owner becomes the "Accountable" or "Responsible" party in a RACI matrix
Earned value at the control account	The work package's chosen measurement technique produces its earned value, which rolls up and is formally reported at its parent control account

That last row deserves precision, since it's a common source of error. Earned value is computed at the work package, using whatever technique that package was assigned. But by the DoD's own definition, the control account, not the individual work package, is the actual management control point, where budgets, actual costs, and earned value get compared for reporting and decision-making. A single struggling work package rarely triggers action on its own. A control account whose aggregated CPI or SPI has slipped gets a variance analysis and a corrective action plan. For the mechanics of that comparison, earned value management walks through the formulas.

Progress measurement methods for a work package

How a work package's percent complete gets calculated is decided before work starts, documented in the dictionary entry, and never changed mid-package. NASA's EVM reference guide and the Department of Defense's EVM glossary both name the same core set of techniques.

Method	How it works	How defensible it is
0/100	Earns 0% until the package finishes, then 100%	Highly defensible; no room for optimistic self-reporting, but only suits very short packages
50/50	Earns 50% the moment work starts, the remaining 50% at completion	Reasonably defensible for short packages; can slightly overstate early progress
Weighted milestones (milestone method)	Assigns a value to specific interim checkpoints inside the package, earning value as each is hit	Defensible when milestones are genuinely objective events, not vague progress claims
Percent complete	The owner reports a completion percentage against the estimate	Widely used but only stays objective with documented backup data supporting the reported figure, per NASA's guide
Units complete	Earns value in proportion to physical units finished (drawings reviewed, workstations installed)	Highly defensible wherever the output is genuinely countable
Level of effort (LOE)	Earns value automatically with the passage of time, used for support-type work with no discrete output	Least defensible for tracking real progress; reserve it for genuinely unmeasurable support work, not as a shortcut

Percent complete without backup data is where most reporting fiction creeps in, since it's the easiest method to report optimistically without anyone catching it. 0/100, units complete, and well-defined weighted milestones are harder to fudge, because they hinge on an event that either happened or didn't. Level of effort is the honest exception: it isn't measuring real progress, it's a bookkeeping convenience for work that was never going to produce a discrete output, and per PMI's guidance, it's best kept to spans of roughly a year or less.

The agile analogue: epics, stories, and sizing instinct

An agile epic or user story is not a work package. They come from different planning traditions, get sized differently, and answer to different owners. But the sizing instinct underneath both is the same: break work down until it's small enough to estimate honestly, own clearly, and finish inside a predictable window.

	Work package	Epic / user story
Sizing basis	Hours of effort (often 8-80)	Relative size, story points, or t-shirt sizing
Owner	One named individual or team	The team collectively, via the sprint
Completion window	Matched to the reporting period	Matched to the sprint or iteration
What proves it's done	Formal acceptance against written criteria	The team's definition of done
Home discipline	Predictive, program-based planning	Scrum, Kanban, hybrid delivery

Hybrid organizations map one to the other constantly, and it mostly works, as long as everyone agrees which side is doing the deciding. A control account can sit above a release's worth of epics the same way it sits above a set of work packages, and a story's acceptance criteria do the same job a work package's do. What breaks the mapping is forcing story points into an hour-based earned value formula. See how the terms actually differ in epics vs. features vs. stories if you're translating between the two worlds regularly.

Common errors in defining work packages

Most work package problems trace back to a small, repeatable set of mistakes, easy to catch once you know to look for them.

Error	What it looks like	Fix
Sized by convenience, not control	A package is however big the person writing the WBS felt like making it that day	Test against the four sizing questions, not just an hour range
Two owners	"Team" or two names sit in the owner field	Split the package, or name one primary owner with supporting contributors listed separately
No acceptance criteria	The package is "done" whenever the owner says so	Write testable criteria before work starts, matching the format used in the WBS dictionary
Decomposed to task level	The WBS has hundreds of line items tracking individual actions, not outputs	Stop decomposing once a package meets the sizing test; let the schedule carry task-level detail
Packages that overlap	Two packages describe overlapping scope, so effort gets double-counted in the estimate	Apply the 100% rule at every level: no gaps, no overlaps
Dictionary written once, never updated	The entry reflects assumptions from kickoff that scope changes have since made false	Update the dictionary through the same change control process that governs the WBS itself

The overlap error deserves a second look, since it's hardest to catch by inspection. Two packages can each look reasonable alone and still double-count the same hours if nobody checks them against each other. That's what the 100% rule exists to catch: walk every branch and confirm the sum of children equals the parent, with nothing missing and nothing counted twice.

Frequently Asked Questions about Work Packages

What is the difference between a work package and a deliverable?

A deliverable is a specific output someone formally hands off and someone else accepts, and it can require several work packages to produce it. A work package is the lowest-level chunk of scope in the WBS, the piece one owner actually plans, estimates, and completes. A deliverable is what gets accepted; a work package is what gets built.

Is a work package the same thing as a schedule activity?

No. A work package is a unit of scope, not a unit of schedule. During planning, a work package gets decomposed into one or more schedule activities, each with a start date, an end date, and dependencies. The work package is the scope container; the activities are what actually populate the project schedule and the network diagram.

What is the 8/80 rule for work packages?

The 8/80 rule is a sizing heuristic stating that a work package should generally take no less than 8 hours and no more than 80 hours of effort. It has no standards body behind it and isn't a hard requirement; some organizations use 4/40 for short efforts or extend to 160 hours on long programs. The underlying goal matters more than the exact number: a package small enough to estimate with confidence, assign to one owner, and track within a single reporting period.

What is the difference between a work package and a planning package?

A work package is scope that has been fully decomposed and can begin: it has an owner, a schedule, and a measurement method, and charges can be booked against it. A planning package is future work within the same control account that has a budget and a target date but hasn't been broken down yet. Per PMI's own guidance, a planning package must convert into one or more work packages before any actual charges hit it.

Where is earned value actually measured, at the work package or the control account?

Both, but they do different jobs. The work package is where a specific measurement technique (0/100, percent complete, units complete, and so on) produces that package's earned value. The control account is the official management control point where that earned value, budget, and actual cost get aggregated and compared for reporting and corrective action. A single struggling work package rarely triggers a response on its own; a control account whose rolled-up performance has slipped usually does.

Can an agile epic or user story be treated as a work package?

Not directly. They come from different planning traditions and are sized differently: an epic or story uses relative sizing or story points, while a work package uses effort hours. The instinct behind both is the same, decompose work until it's small enough to estimate and own clearly, but forcing story-point data into an hour-based earned value formula usually causes more confusion than it resolves.

How many work packages should a project have?

Enough to fully decompose every deliverable and no more. There's no target count; it depends on project size and the sizing range chosen. Hundreds of work packages for a modest scope usually means over-decomposition, task-level detail masquerading as work packages, while a handful covering a large deliverable usually means they're sized too big to estimate or track with confidence.

A work package earns its place in the WBS by doing a job nothing else in the plan can do: giving one person a piece of scope small enough to own, estimate honestly, and finish inside a window someone can check. Get the sizing test right, write the dictionary entry with real acceptance criteria, and keep planning packages honest about what hasn't been detailed yet, and the rest of the plan inherits something worth building on instead of a guess wearing a project plan's clothes.

About the author

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.

View full profile LinkedIn