Feature

Origin & evolution

Feature is older than agile and entered software planning as the obvious answer to "what does the product do?". Its sharpest framing came from outside engineering, in the marketing distinction between a feature and a benefit: a feature is an attribute of the product, a benefit is the change it produces for the person using it. Teams that confuse the two can ship attributes that do not change anything for the user.

Two bodies of practice pushed the definition forward. Marty Cagan, in *Inspired* and then *Empowered*, drew the line between a "feature team" that is handed features to build as output and an empowered product team measured on the customer and business problems it solves. The feature stops being the deliverable and becomes one possible solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →, kept or discarded on the evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →. Ryan Singer's Shape Up attacked the open-ended feature from another angle, with the appetite: the team fixes how much time a piece of functionality is worth, typically a six-week cycle, then shapes the work to fit that budget so an unbounded feature cannot consume whatever it takes.

The field has largely converged on a discipline around the word. The feature remains the natural unit of shippable value, and the surrounding practice exists to keep it tied to an outcome🏆OutcomeStrategyA desired business or user outcomeView reference →, so the question shifts from "did we ship the feature?" to "did the feature move the thing it was meant to move?".

How it works in practice

A team ships a feature: saved filter views in an analytics product. It is distinct, a user can name it, and it delivers value alone. The trap would be to call it done at launch. The empowered framing attaches the feature to the problem it was meant to solve, that analysts rebuild the same query every morning, and to a measurable result, the share of sessions that start from a saved view.

Shaped against a four-week appetite, the team builds the core save-and-recall path and deliberately drops view sharing and scheduled exports, parking them as separate bets. Three weeks after release, forty per cent of returning analysts open a saved view on login and average time-to-first-chart drops by half. That outcome is what justified the feature; the saved view itself was the mechanism.

Feature vs. its neighbours

• Benefit. A feature is what the product does; a benefit is what the user gains. "Saved filter views" is a feature, "stop rebuilding the same report every morning" is the benefit. The feature lives on the roadmap, the benefit lives in the user's day, and the two should always be traceable to each other.
• Capability💪CapabilityStrategyAn ability that enables value deliveryView reference →. A capability is a higher-level ability of the system or organisation, often spanning several features. In SAFe a capability sits above features and can cross multiple teams. "Self-serve analytics" is a capability; the saved view is one feature inside it. A capability answers what the product can broadly do; a feature is a concrete, shippable slice of it.
• Epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference →. An epic is a large goal that is expected to break into several features or stories before it can ship. A feature is releasable on its own. The difference is shippability and size: you announce a feature, you decompose an epic.

In the graph

In the Unified Product Graph the feature is the anchor of the Product & Delivery region, chosen as the entity that answers the narrowest version of "what did we commit to?". It decomposes downward through feature_decomposed_into_epicFeaturedecomposed intoEpichierarchy into the work-breakdown spine, and its boundary edges are what keep it honest. feature_addresses_jobFeatureaddressesJobcross-domain ties it to the user need🫀NeedUserA user need, pain, desire, or constraintView reference → it serves, feature_drives_key_resultFeaturedrivesKey Resultcross-domain connects it to the outcome it is meant to move, and outcome_delivered_by_featureOutcomedelivered byFeaturecross-domain lets strategy point back the other way. Because every feature node can be traced to a job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → and a result, the graph makes the Cagan critique structural: a feature wired to functionality but to no job and no key result📈Key ResultStrategyA measurable result tied to an objectiveView reference → is, by construction, output without evidence of value. 0.35.0 added the rung the spine was missing. feature_specified_by_user_storyFeaturespecified byUser Storyhierarchy lets a feature reach the stories that specify it without passing through an epic, and user_story💬User StoryProduct SpecificationA user's goal and the value they expect, in the "As a… I want… So that…" format. Now also a first-class plannable unit (priority, effort, assignee, due_date) that schedules into a planning_cycle, and it round-trips an external board's column via workflow_state.View reference → joined the feature's valid children alongside epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference →, bug🐛BugProduct SpecificationA defect or unexpected behaviourView reference → and task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →. The verb pair is cloned from epic_specified_by_user_storyEpicspecified byUser Storyhierarchy so the two rungs of the ladder read identically; a contains-style verb would have been the duplicated parent link the architecture forbids. Because the epic level is optional, a feature that skipped it previously had no path to its own stories, which made the decomposition spine look complete while leaving a real gap in it. Per-instance parentage is unchanged: a story still has one parent_id.