Skip to Content
DocsNeedsNeeds Hierarchy
DRAFT — This document is under development and not yet reviewed.

Needs Hierarchy

Updated 15 May 2026

The needs hierarchy defines the artifacts that carry needs through the delivery system — from strategic investment decisions at portfolio level to implementation work at team level. Each level has a distinct purpose, ownership, and scope.

This hierarchy is within the needs domain — the part of the delivery system that builds and delivers. The requirements domain (constraints that persist rather than items that flow) is described separately in Needs and Requirements.

The hierarchy is not a decomposition exercise. It is a flow design. Each artifact is the primary unit of flow at its level — initiatives flow through Portfolio Kanban, features flow through DVS Feature Kanban, stories flow through team backlogs.

Core Hierarchy

Most organizations are well-served by three levels:

Portfolio level    →  Initiative
DVS level          →  Feature
Team level         →  Story

Initiative

A significant investment requiring Portfolio-level approval and governance. An Initiative is a bet — it articulates a problem worth solving, a hypothesis about how to solve it, and an expected outcome.

  • Focus: Why — what problem, what expected outcome
  • Scope: 3 months to multi-year; typically spans one or more DVSs
  • Owned by: Initiative lead
  • Decided by: Lean Portfolio Management
  • Unit of flow in: Portfolio Kanban

An Initiative is not a project plan. It is a value hypothesis with a lean business case. The solution is deliberately underspecified at this level — that detail belongs at DVS and team level.

See also: Portfolio Kanban Flow, Portfolio Flow Metrics

Feature

A deliverable capability that fulfills a stakeholder need within a DVS. A Feature is a solution hypothesis — a specific way the DVS believes it can deliver part of an Initiative’s intended value.

  • Focus: What — a defined capability with a benefit hypothesis and acceptance criteria
  • Scope: Deliverable by a single DVS within one Program Increment
  • Owned by: Product Owner
  • Unit of flow in: DVS Feature Kanban

Feature types:

  • Business Feature — delivers direct customer or user value
  • Enabler Feature — supports future business functionality: architecture, infrastructure, compliance, security

A healthy DVS maintains a conscious balance between the two. Enabler Features are not second-class — they are the investment in delivery capability that makes future Business Features possible.

See also: DVS Kanban Flow, DVS Flow Metrics

Story

The team’s unit of work — a specific, testable behavior described from the user’s perspective.

  • Focus: What — concrete behavior, acceptance criteria, testability
  • Scope: Completable within a single iteration (sprint)
  • Owned by: Product Owner (implemented by the development team)
  • Unit of flow in: Team backlog / team Kanban

Stories are derived from Features. A Feature is not done until its constituent Stories are done and integrated.

Extended Hierarchy

Organizations with multiple portfolio levels or genuine cross-DVS coordination needs may extend the core hierarchy.

Domain Initiative (optional)

A domain-specific investment decision — either a decomposition of a Strategic Initiative or a standalone domain investment. Relevant when the organization has multiple portfolio levels (enterprise portfolio + domain portfolios).

  • Scope: 3–12 months, may span multiple DVSs
  • Owned by: Domain Product Owner / Product Manager
  • Decided by: Domain portfolio governance

When to use: When the organization has distinct domains with their own investment governance and budget authority. Not needed if the organization operates a single portfolio.

Cross-DVS Flow (advanced, use sparingly)

A coordination artifact for features that span multiple DVSs and require explicit end-to-end management.

  • Scope: 2–6 months, multiple DVSs, complete user journey
  • Owned by: Solution Architect / Product Manager
  • Used only when: Genuine cross-DVS integration is required — shared release, end-to-end testing across systems, or a complete user experience that cannot be decomposed into independent DVS deliveries

This artifact introduces coordination overhead. Before using it, exhaust the options for decomposing the need into independent DVS features that can be delivered separately. Cross-DVS Flow is the right tool when those options are genuinely not available.

Traceability

Every artifact should be traceable upward to its parent Initiative. This is not bureaucratic record-keeping — it is what makes the delivery system coherent. When a team asks “why are we building this?”, traceability provides the answer.

Practical principles:

  • Business value is established at Initiative level and inherited downward
  • Features carry the Initiative’s value argument forward — they should be justifiable in terms of the Initiative’s expected outcomes
  • Stories carry the Feature’s acceptance criteria forward into testable behaviors
  • Dependencies between artifacts at the same level are documented explicitly

What the Hierarchy Is Not

Not a sequential process. Initiatives do not need to be fully defined before Features are analyzed. Features do not need to be fully specified before Stories are written. The system is iterative at every level.

Not a handoff chain. Portfolio does not hand off to DVS, which hands off to teams. The levels are concurrent — portfolio is managing initiatives while DVS is delivering features while teams are completing stories.

Not a bureaucratic approval ladder. The hierarchy exists to create clarity and flow, not to add gates and checkpoints. Governance at each level should be the minimum necessary to make good investment decisions.

OverviewNeeds and Requirements