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

Initiative

Updated 30 March 2026

An Initiative is a significant investment requiring portfolio-level governance. It is a value hypothesis — a statement of what problem is worth solving, what outcome is expected, and what investment is justified to find out.

Some investments span multiple years and are governed as Strategic Initiatives. Both types flow through the Portfolio Kanban system and both require a Lean Business Case. They differ in horizon and in what happens during Continuous Discovery.


The Portfolio Needs Hierarchy

Initiatives exist within a four-level hierarchy of value hypotheses. Each level frames a bet about what is worth doing — from multi-year strategic direction to the individual story a team delivers in a sprint.

LevelTypeGoverned atHorizon
PortfolioStrategic InitiativePortfolio Kanban1.5–5 years
PortfolioInitiativePortfolio KanbanUnder 18 months
DVSFeatureDVS KanbanPI cadence
TeamStoryTeam KanbanSprint

This is not a Work Breakdown Structure. The relationship between levels is traceability and alignment — not decomposition. An Initiative must be justifiable against its Strategic Initiative’s investment hypothesis. A Feature must be justifiable against its Initiative’s value hypothesis. But none of these are work packages that “belong to” the level above. Each is an independent value hypothesis in its own right, with its own flow, its own go/no-go decision, and its own outcome assessment.


What an Initiative Contains

Problem Statement

A clear description of the problem, opportunity, or strategic need the Initiative addresses. The problem statement answers: what situation exists today that we need to change, and why does it matter?

A good problem statement is specific enough to be falsifiable — you can recognize whether it has been addressed.

Value Hypothesis

The expected outcome if the Initiative succeeds. Stated as a measurable or observable change, not as a list of features to deliver.

Examples of value hypotheses:

  • Reduce onboarding time for new enterprise customers from 30 days to under 10
  • Eliminate manual reconciliation by automating the month-end close process
  • Enable self-service configuration so customers can make changes without contacting support

The hypothesis is a bet. It may be wrong. The delivery system should be designed to test it, not just execute against it.

Lean Business Case

A lightweight investment justification — the minimum analysis required to make a good-enough go/no-go decision. Both Initiatives and Strategic Initiatives require a Lean Business Case. The Strategic Initiative LBC operates at a higher level of abstraction; its primary output from Continuous Discovery is the breakdown into Initiatives, each with their own LBC.

Elements of a Lean Business Case:

  • Strategic alignment — which strategic themes and OKRs does this Initiative support, and how strongly?
  • Problem — what situation are we addressing, and what is the cost of not addressing it?
  • Solution hypothesis — what approach do we believe will work? What alternatives were considered?
  • Independent operability plan — how will this Initiative function on its own, and how will it coexist with existing systems during rollout?
  • MVP definition — what is the smallest version that will start validating the hypothesis?
  • Cost estimate — order-of-magnitude investment required
  • Expected outcomes — what measurable change will we use to evaluate success?
  • Go/no-go criteria — what conditions would lead to a decision to pivot or stop?

The Lean Business Case is intentionally brief. Its purpose is a decision, not a comprehensive plan. Over-specification at this stage is waste — the DVS and teams will determine how to build the solution.


Sizing

Sizing reflects the team’s assumption about what is achievable within the horizon — not a prediction of complexity.

Initiative

SizeHorizon
XSUnder 6 months
S6–9 months
M9–12 months
L12–18 months
XLOver 18 months

An Initiative sized XL should be examined carefully. If the hypothesis cannot be meaningfully validated within 18 months, consider whether the investment is better governed as a Strategic Initiative.

Strategic Initiative

SizeHorizon
S1.5–2 years
M2–3 years
L3–5 years

Strategic Initiatives

A Strategic Initiative is a multi-year investment decision. It flows through the Portfolio Kanban alongside Initiatives, but its behaviour in Continuous Discovery is different: the primary output is not a single Lean Business Case ready for delivery — it is the breakdown into Initiatives, each with their own LBC and their own go/no-go decision.

A Strategic Initiative is in Continuous Delivery when one or more of its Initiatives are in Implementing. It is not a prerequisite that all Initiatives are defined before any of them enters delivery — the breakdown continues as a learning process throughout the Strategic Initiative’s lifecycle.

Breakdown Must Follow Value, Not Technical Structure

Identifying meaningful slices requires understanding the end-to-end business flow — the major customer and operational flows the organization wants to improve or replace. Without this understanding, breakdown defaults to technical or organizational structure rather than value.

WBS-style breakdown — value deferred:

Initiative 1: Build data model and API Initiative 2: Build customer flow, steps 1–3 Initiative 3: Build customer flow, steps 4–6 Initiative 4: Build reporting → Value is only delivered when all four are complete

Value-based breakdown — each Initiative independently operable:

Initiative 1: Customers can complete X (limited scope, fully operational) Initiative 2: Customers can also do Y (extends Initiative 1) Initiative 3: Customers can also do Z (extends further) → Each Initiative is deployable and can be validated in use

Large programs fail when nothing works until everything works.

The Independent Operability Requirement

Each Initiative within a Strategic Initiative must result in a solution that works in production on its own — even if it does not yet replace existing systems or cover the full scope of the Strategic Initiative.

This is not primarily a technical requirement. It is the principle that makes agile delivery of large systems possible. The decision to go live and replace existing systems is a business decision, not a technical dependency. An Initiative may run alongside legacy systems during rollout — through parallel operation, gradual migration, or incremental handover — until the organization decides the new solution is ready to take over. Planning for this coexistence is part of the Lean Business Case.


Lifecycle

An Initiative moves through the Portfolio Kanban from Intake to Done. The key transition is the go/no-go decision at Gate 2 — this is when the Lean Business Case is evaluated and the investment is either approved or stopped.

A Strategic Initiative follows the same path. It enters Done when its scope has been fully delivered through its Initiatives, the investment is stopped, or portfolio-level governance is no longer required.

Once in Implementing, an Initiative is not handed off and forgotten. Portfolio governance tracks progress, reviews outcomes at milestones, and makes explicit decisions to continue, pivot, or stop.

See: Portfolio Kanban Flow for stage definitions and gate criteria.


Ownership

ResponsibilityOwner
Defines and maintains the InitiativeInitiative Owner
Go/no-go decisionPortfolio management function
Portfolio flow governancePortfolio management function
Solution deliveryDVS(s) assigned

The Initiative Owner is accountable for the value hypothesis — ensuring the problem is well understood, the expected outcomes are tracked, and decisions about scope and direction are made throughout delivery.


Relationship to Features

An Initiative does not contain features. Features are how a DVS proposes to deliver the Initiative’s value — they are defined at DVS level, not portfolio level. Multiple DVSs may each contribute features toward the same Initiative.

The connection is traceability and alignment, not hierarchy. A Feature should be justifiable in terms of its parent Initiative’s value hypothesis: if you cannot explain how this feature contributes to the expected outcome, the feature may be misaligned or the Initiative may need re-scoping.

See: Artifact: Feature


Sources

  • ReinertsenPrinciples of Product Development Flow (2009). Queue theory, WIP management, and the economic basis for prioritization.
  • AndersonKanban (2010). Pull systems, flow policies, and class of service.
  • Humble & FarleyContinuous Delivery (2010). Continuous validation and feedback loops in delivery systems.
  • Gothelf & SeidenLean UX (2013). Hypothesis-driven investment thinking.
  • CaganInspired (2017). Discovery as a continuous organizational capability.