The Semantics of Planning: Getting the Words Right

Language is not decoration. In engineering and process methodology, the words we choose determine the mental models we build. Imprecise language produces imprecise thinking — and imprecise thinking produces systems that don’t hold together.

Part One: Product Decomposition

When we decompose a product, we are working through three distinct perspectives simultaneously: what the customer perceives and is willing to pay for, what the system must be able to do, and what specific behaviors the system performs. These are not the same thing. They deserve different words.

Feature is a customer-facing term. It names what a product has — what a customer can perceive, evaluate, and decide to pay for. “Heated seats” is a feature. The customer does not care about the thermodynamics involved. They care that the seat gets warm. Features are promises made at the point of sale. They live in brochures, option lists, and pricing sheets. A product is marketed by its features.

Capability is a system-facing term. It names what a system must be able to do in order to deliver a feature. “Thermal regulation of the seat surface” is a capability. It describes the system’s competency, not the customer’s experience. A capability is verifiable — either the system has it or it doesn’t. A product is engineered through its capabilities.

Function is a behavioral term. It names the specific action a system performs — the atomic, testable unit of behavior. “Maintain 38°C at the seat surface under ambient conditions between −20°C and +40°C” is a function. It is precise enough to write a test against. A product is verified at the level of its functions.

The relationship is hierarchical and directional. A Feature names what the customer perceives and pays for — “heated seats” — and is the concern of marketing, sales, and the product owner. A Capability names what the system must be able to do — “thermal regulation of seat surface” — and is the concern of the systems engineer and architect. A Function names the specific behavior performed — “maintain 38°C at seat surface” — and is the concern of design, test, and verification.

Features are promises. Capabilities are proofs. Functions are mechanisms.

This hierarchy matters because the failure modes at each level are different. You can fail to deliver a feature by promising what the system cannot do. You can fail at a capability by designing something that cannot be consistently achieved. You can fail at a function by specifying behavior that is incomplete or untestable. Good systems engineering keeps these levels distinct and traces between them explicitly.

Part Two: Where the Frameworks Go Wrong

SAFe — and many other scaled agile frameworks — invert the Feature/Capability relationship. In SAFe, Capabilities sit above Features in the hierarchy. A Capability in SAFe is a large cross-cutting thing a system can do, and Features are decompositions of that Capability.

This is not wrong so much as it is inside-out. It adopts the perspective of the enterprise architecture team looking down at the system, rather than the customer looking at the product. The problem is not the logic — it is that the same words are now being used to mean different things depending on whose framework you happen to be in that week. Teams end up arguing about hierarchy levels instead of doing the work.

The root cause is that “Feature” was coined in product marketing and “Capability” was coined in enterprise architecture. They were never reconciled before frameworks adopted them. The collision is baked in, and most methodologists just picked a side without acknowledging the other.

The resolution is to anchor your definitions to a single consistent perspective and hold the line. In customer-value-anchored, regulated-product development — the kind where ASPICE, ISO 26262, or DO-178C apply — the outside-in hierarchy maps cleanly to the distinction between stakeholder requirements, system requirements, and detailed design. Features are what stakeholders want. Capabilities express what the system must achieve. Functions specify how it behaves. This is not a new idea. It is what good systems engineering has always said.

Part Three: Planning and Work Management

The same principle applies to the words we use to organize and schedule work. The product decomposition stack — Feature, Capability, Function — tells us what to build. The work decomposition stack tells us how to organize the people and time needed to build it. These are parallel concerns, and they need their own precise language.

Story is the atomic unit of deliverable work. It must be completable within a single sprint. It is not a wish or a requirement in the abstract — it is a slice of work with a clear done condition. “Done means done” is not a slogan; it is the operational definition of a Story. If it cannot close within the sprint, it is not a Story — it is something larger that has not been decomposed properly.

Work Package — commonly called an Epic — is the quartile container: one team, one quarter, a coherent set of Stories that advances delivery toward a capability. The natural size is approximately one sprint of setup and enablement followed by five delivery sprints, giving a six-sprint cycle that maps cleanly to the shortest business planning horizon at which investment decisions, capacity commitments, and outcome reviews can meaningfully occur. The Work Package resolves at the quarter boundary. In the literary sense from which “Epic” is borrowed, an epic is a long-form narrative that reaches resolution — which is precisely what a quarterly work cycle should do. The terms are interchangeable; what matters is that the concept is understood as one team, one quarter.

That definition works cleanly for straightforward delivery. But two conditions arise in real program work that break the single-team/single-quarter boundary — and when either condition is present, a higher coordination layer is needed.

The first condition is multi-quarter scope: the capability is too substantial to deliver in a single quarter and must be planned across several consecutive Work Packages. The second condition is multi-team scope: the capability requires more than one team working in parallel or sequence — a software team, a hardware team, and a safety assurance team may all need to contribute before the capability can be declared delivered.

In both cases, what is needed is a container that owns the capability definition across time and teams, coordinates the Work Packages beneath it, and carries its own done condition — not “stories closed” but “capability verified.” This is the Capability Package.

The Capability Package is semantically precise because it names what the thing is: the unit of work at which a system capability is planned, coordinated, and ultimately verified. It is the layer at which you ask “can the system now do this thing?” — which is a fundamentally different question from “did the team complete this quarter’s work?” That distinction in done condition is what separates the Capability Package from the Work Package beneath it. It is not a size difference. It is a nature difference.

This is also where Saga can find its legitimate home — if you prefer the term. In its Norse literary origins, a saga is a multi-generational narrative spanning many actors and many seasons before it resolves. That maps honestly onto a multi-team, multi-quarter capability delivery arc. The problem with Saga in most frameworks is not the word itself but that it is introduced without clear trigger conditions, making it feel like hierarchy for hierarchy’s sake. Anchored to the two explicit triggers above — multi-quarter or multi-team — it earns its place.

The clean hierarchy, with product and work decomposition aligned, reads from the top down as follows. An Initiative is the strategic investment horizon spanning one to three years. A Feature is the market promise — what the customer pays for. A Capability Package is the multi-team and/or multi-quarter delivery unit that proves the feature can be delivered. A Work Package (Epic) is one team for one quarter, roughly six sprints. A Story is a sprint-sized unit of work with a verifiable done condition. A Task is a sub-day work unit internal to a Story.

The Capability Package is the bridge between the product decomposition and the work decomposition. Above it, the language is about what the system is and does. Below it, the language is about how teams organize and execute. That boundary is worth making explicit — because when it is invisible, planning conversations collapse the two concerns together and produce plans that are neither good product thinking nor good delivery thinking.

The Governing Principle

Use the term that names what the thing is, not what container size it happens to fit in this sprint.

Stories are not small Epics. They are sprint-bounded units of verifiable work — a different nature, not just a different size.

Work Packages are not big Stories. They are quartile delivery plans for a single team — again, a different nature.

Capability Packages are not very big Work Packages. They are the coordination and verification layer for capabilities that span teams or quarters — a different nature still.

Features are not Capabilities. One is a customer perception; the other is a system competency.

Capabilities are not Functions. One names what a system can do; the other specifies the precise behavior it performs.

When we use these words with precision, planning conversations change character. Teams stop debating whether something is “too big for a Story” and start asking whether the decomposition is semantically correct — which level does this belong at, and does it have the right done condition for that level? That is a better conversation. And it leads to better systems.

---

David Rush is a Systems Engineering and Process Methodologist with more than 30 years of experience in regulated product development across automotive, aerospace, and critical infrastructure.