Feature
A Feature is a deliverable capability that fulfills a stakeholder need within a DVS. It is the primary unit of flow through the DVS Feature Kanban system.
A Feature is not a requirement in the traditional sense. It is a solution hypothesis — a specific, scoped capability the DVS believes will contribute to an Initiative’s expected value. It can be wrong. Acceptance criteria exist to make wrongness detectable.
What a Feature Contains
Benefit Hypothesis
A statement of the value the Feature is expected to deliver — to customers, users, or the organization. The benefit hypothesis answers: why are we building this, and what change do we expect to see when it is done?
The benefit hypothesis connects the Feature back to its parent Initiative. A Feature without a clear benefit hypothesis is a scope item, not a value delivery unit.
Acceptance Criteria
The conditions that must be true for the Feature to be considered done. Acceptance criteria define the boundary of the Feature’s scope and make the benefit hypothesis testable.
Good acceptance criteria are:
- Specific and unambiguous
- Testable — someone can verify them without guessing
- Owned by the Product Owner
- Written before development begins
Acceptance criteria are not a test script. They define what must be true — not how to verify it.
WSJF Score
Features are prioritized using Weighted Shortest Job First. WSJF maximizes economic value delivered over time by sequencing work with the highest value per unit of time first.
WSJF = Cost of Delay / Job Duration
Cost of Delay captures three components:
- User and business value — how much value does this deliver?
- Time criticality — does the value decay if we wait?
- Risk reduction / opportunity enablement — does this unblock or de-risk other work?
WSJF is a relative scoring tool, not an absolute measure. Scores are meaningful in comparison to other Features in the same backlog — not in isolation.
Feature Types
Every Feature is either a Business Feature or an Enabler Feature.
Business Feature delivers direct value to customers or users — new or improved capability that addresses a need.
Enabler Feature invests in the delivery capability that makes future Business Features possible: architectural runway, infrastructure, platform, compliance, security hardening, technical debt reduction.
A healthy DVS maintains a conscious balance between the two. Enabler Features are not second-class work. Neglecting them creates the technical conditions that slow or block Business Feature delivery over time.
Typical distribution: 70–80% Business Features, 20–30% Enabler Features. Significant deviation in either direction warrants investigation.
Sizing and Splitting
A Feature should be deliverable by a single DVS within one Program Increment (typically 8–12 weeks). A Feature that consistently takes longer than one PI to deliver is a signal: either the scope needs splitting, or the DVS has a capacity or dependency problem worth understanding.
Splitting principles:
- Split by workflow step — deliver one part of the capability end-to-end
- Split by data or user segment — deliver the full capability for a subset
- Split by scenario — deliver the common case first, edge cases in subsequent features
- Do not split by technical layer — back-end only or front-end only features deliver no user-visible value
Ownership
| Responsibility | Owner |
|---|---|
| Defines the benefit hypothesis | Product Manager / Product Owner |
| Maintains and prioritizes the Feature Backlog | Product Management |
| Acceptance and done decision | Product Owner |
| Delivery | DVS development teams |
Relationship to Initiatives and Stories
A Feature traces upward to the Initiative that motivated it. The connection should be explicit — a Feature whose link to an Initiative’s value hypothesis cannot be articulated is a candidate for re-examination.
A Feature traces downward to the Stories that implement it. The Feature is not done until its constituent Stories are done and integrated. The sum of Stories should satisfy the Feature’s acceptance criteria.