Glossary
Updated 15 May 2026
Terms are listed alphabetically. Where a term originates from or overlaps with a specific framework (SAFe, LeSS, Lean), that context is noted — but definitions here reflect how the term is used in ASP.
A
Acceptance Criteria
owner: model
The conditions that must be true for a work item to be considered done. Written before development begins. At Feature level: defines the boundary of scope and makes the benefit hypothesis testable. At Story level: defines specific behaviors, edge cases, and constraints the implementation must satisfy.
Agile Release Train (ART)
owner: model
A SAFe-specific organizational construct — a team of teams (typically 50–125 people) operating on a shared PI cadence within a value stream. In ASP, the equivalent concept is the Development Value Stream (DVS). The terms are often used interchangeably in SAFe implementations, but ASP separates the organizational structure (DVS) from the flow of work through it.
Agile Coach
owner: role
A team-level role responsible for supporting the team’s flow and continuous improvement. Facilitates team events, removes impediments, and coaches the team in lean-agile ways of working. Not a project manager.
See: Team Roles
Agile Team Member
owner: role
The core delivery role in a lean-agile team. Responsible for end-to-end delivery — design, build, test, and operate — within the team. Cross-functional by expectation. Also referred to as Dev Engineer.
See: Team Roles
Agile Thinking
owner: thinking
A response to uncertainty — replacing the assumption that work can be fully planned upfront with a discipline of short cycles, fast feedback, and continuous adaptation. One of the five foundational thinking disciplines in ASP.
See: Agile Thinking
Analytical capacity
owner: capability
One of two specific forms of capacity at portfolio level (the other is delivery capacity). The capacity to mature initiative candidates from idea to investment-ready — consumed in the Triage, Investigate, and Investment Framing stages of the portfolio flow. Funded differently from delivery capacity, populated by different competencies, and bottlenecked at different points; a single portfolio-wide WIP number conflates them.
See: Capacity · Capacity and Flow Management · Discovery domain
B
Benefit Hypothesis
owner: model
A statement of the value a Feature is expected to deliver — to customers, users, or the organization. Answers: why are we building this, and what change do we expect to see when it is done? Connects the Feature back to its parent Initiative. A Feature without a clear benefit hypothesis is a scope item, not a value delivery unit.
See: Feature
Business Feature
owner: model
A Feature type that delivers direct value to customers or users — new or improved capability that addresses a need. One of two Feature types; the other is Enabler Feature.
See: Feature
Business Rule
owner: model
A domain constraint that describes the stable logic of the business — calculation rules, validation rules, state transition rules, authorization logic, decision rules. Independent of any specific feature. Long-lived, often driven by law, regulation, or business policy. Should be documented and versioned separately from features.
See also: Domain Requirements
Business Analyst
owner: role
A competence that supports the Product Owner and team in translating business needs into backlog items and clarifying domain understanding. Embedded in the team or shared with product management — not a central requirements function that owns requirements on behalf of others.
See: Team Roles · DVS Roles
Business Sponsor
owner: role
A portfolio-level role that holds the organizational authority and executive alignment for a significant initiative. Participates in portfolio governance at key decision points.
See: Portfolio Roles
Budget Guardrail
owner: model
A boundary defined by the portfolio within which a value stream may operate autonomously without portfolio-level approval — for example, the investment mix between new capability and technical enablement, exposure to a single initiative, or any spend category requiring organizational visibility. Set during allocation; respected continuously. Distinct from delivery guardrails (e.g. quality, security policy) — Budget Guardrails govern financial autonomy specifically.
See: Financial Governance
C
Capability
owner: capability
An ability the delivery system possesses — what it is able to do, independent of how, when, or who realizes it. In ASP, capabilities are modeling concepts in the capability modeling tradition (Vintergatan/IRM, TOGAF): stable abilities distinct from the practices, flows, or roles that realize them.
See: Index
Capacity
owner: capability
What the delivery system currently has free — its available room to take on more work. Composed of current load, flow rate, and the timing of when capacity is likely to open. Distinct from Capability: Capability is what the system can do structurally; Capacity is what it currently has free. Both feed feasibility assessment.
At portfolio level, capacity manifests in two specific forms: analytical capacity (consumed in upstream stages — Triage, Investigate, Investment Framing) and delivery capacity (consumed in Implementing by value streams). The Capacity Buffer is a finance-side mechanism that holds part of allocated capacity unallocated to absorb demand variability.
See: Capacity and Flow Management · Analytical capacity · Delivery capacity · Capacity Buffer
Capacity and Flow Management
owner: capability
The capability to set work-in-progress limits across the portfolio flow and to maintain the pull-discipline that keeps initiatives flowing through those limits. Operates in two halves separated by cadence: setting the capacity frame as empirical adjustment reveals what limits should be, and operating the flow continuously through pull-discipline at stage boundaries.
See: Capacity and Flow Management · Capacity · WIP Limit
Cadence
owner: thinking
A regular, predictable rhythm for planning, delivery, and synchronization. Cadence reduces coordination overhead by making events and decisions happen on a known schedule rather than ad hoc.
Capacity Buffer
owner: model
A defined proportion of a value stream’s budget held as unallocated reserve within that allocation, available for variable capacity when demand temporarily exceeds stable capacity. The buffer is part of the value stream’s own funding, not a separate pot. An explicit hedge against demand variability — not slack. Specific buffer sizing and how the buffer is realized are practice-level concerns.
See: Financial Governance
CD3
owner: capability
A practitioner formulation of cost-of-delay-based sequencing — Cost of Delay divided by Duration. Originated by Joshua Arnold (Black Swan Farming). One of several models that operationalize Reinertsen’s principle of ranking by cost of delay per unit of size.
See: Initiative Prioritization
Clarity
owner: capability
How well an initiative is understood — what it is, why it is being done, and what it requires. A component of Confidence (Cohn, Agile Estimating and Planning, 2005). In lean-agile thinking, clarity is progressive and decision-specific: the question is whether the initiative is well enough understood to support the decision at hand, not whether everything is fully specified before starting. Different decisions require different clarity thresholds; a Definition of Ready operationalizes the threshold for each gate.
See: Initiative Prioritization · Definition of Ready
Class of Service
owner: capability
A flow-policy categorization that captures different cost-of-delay profiles — typically expedite, fixed-date, standard, and intangible (Anderson, Kanban, 2010). Each class has its own pull and prioritization rules. An alternative to numerical cost-of-delay scoring when quantification is unreliable.
See: Initiative Prioritization
CoD-driven sequencing
owner: capability
The mechanic of ordering initiatives by cost of delay relative to size, so smaller, more time-sensitive, higher-value initiatives move ahead of larger, less urgent, lower-value ones. The principle (Reinertsen) is implemented through several practitioner formulations including CD3 and Class of Service.
See: Initiative Prioritization · Cost of Delay
Commitment Reliability
owner: metrics
The percentage of initiatives delivered as committed after a GO decision.
(Initiatives delivered as committed / Total with GO decision) × 100
A portfolio-level metric measuring whether the organization honors its investment decisions.
Commitment Stability
owner: metrics
The number of formal re-baseline decisions made after an initiative receives a GO decision. Zero indicates high stability; two or more indicates systemic uncertainty or poor upfront analysis. Also measured at portfolio level as the percentage of active initiatives without re-baseline.
Committed
owner: flow
Stage 5 in the DVS Feature Kanban. Features sequenced into the current PI at PI Planning. A pull queue — no active work in progress. Distinct from the PI Backlog: a feature in Committed is a team commitment for the current PI; a feature in the PI Backlog is a candidate for a future PI.
Confidence
owner: capability
The composite reliability of an investment judgment — how much the assessments of value, time horizon, size, and feasibility can be trusted. Composed of multiple uncertainty sources (Cohn): uncertainty about the value, uncertainty about the size, and uncertainty about the initiative itself (clarity). Not a separate dimension competing with the others — a meta-property of the whole judgment.
See: Initiative Prioritization
Continuous Delivery
As principle (owner: principle):
Structuring work so that value reaches users frequently — in short, predictable cycles rather than large, infrequent releases. Reduces the cost of being wrong, accelerates learning, and creates a sustainable delivery rhythm.
See: Continuous Delivery
As phase in Portfolio Kanban Flow (owner: flow):
The third phase of the Portfolio Kanban flow — covering the Implementing stage. Its purpose is to turn approved initiatives into delivered outcomes through the value streams. Continuous Initiative Validation is active throughout this phase, asking whether each initiative’s hypothesis still holds as delivery progresses.
Continuous Discovery
As thinking discipline (owner: thinking):
An ongoing practice of understanding user needs in parallel with delivery — not as a phase that completes before development begins. Teams regularly talk to users, observe behavior in production, and test assumptions with small experiments. Discovery and delivery run concurrently.
Grounded in: Product Thinking
As phase in Portfolio Kanban Flow (owner: flow):
The second phase of the Portfolio Kanban flow — covering Investigate and Investment Framing. Its purpose is to mature candidates that have passed Gate 1 from initial framing to an investment-ready Lean Business Case at Gate 2. Continuous because initiatives enter and exit the phase throughout the cycle, not at a single planning event.
Continuous Learning
owner: flow
The fourth phase of the Portfolio Kanban flow — covering the Outcome & Learning stage. Its purpose is to assess whether delivered initiatives produced the outcomes their Lean Business Cases predicted, and to synthesize learning across initiatives into intelligence that improves future investment decisions. Continuous because outcome assessment runs in parallel with delivery of other initiatives, not as a separate post-portfolio activity.
Distinct from Continuous Learning and Improvement — the ASP principle about ongoing system-level learning. The principle applies to the entire delivery system; this phase is a specific zone in the Portfolio Kanban flow.
See: Portfolio Kanban Flow · Outcome Measurement and Learning
Continuous Learning and Improvement
owner: principle
The ongoing, systematic practice of understanding how the delivery system works and improving it — through learning from measurement, retrospectives, and experiments, then acting on what is found. Not a periodic transformation program — a permanent operating mode.
See: Continuous Learning and Improvement
Continuous Sensing
owner: flow
The first phase of the Portfolio Kanban flow — covering Intake and Triage. Its purpose is to make all incoming demand visible and filter it for strategic relevance before any analytical investment is made. Continuous because submissions arrive throughout the cycle, not at a single planning event.
Continue
owner: capability
The active portfolio decision to keep an initiative in delivery on the strength of validation evidence. Distinct from the absence of a decision — Continue is explicitly made, not assumed. One of the three decisions produced by Continuous Initiative Validation.
See: Continuous Initiative Validation · Pivot · Stop
Cost in Progress (CIP)
owner: metrics
The total cost currently invested in active work items — at initiative level (Triage through Implementing) or at portfolio level (aggregated across all active initiatives). Measures economic exposure. High CIP relative to throughput signals overinvestment relative to delivery capacity.
Cost of Delay
owner: principle
The economic impact of not delivering value now — what it costs the organization to wait on a decision or delivery. Cost of Delay is a key input to value-based prioritization: work with high cost of delay and short delivery duration is prioritized first.
See also: WSJF
Cost Predictability
owner: metrics
A measure of how closely actual costs match forecasted costs.
1 − |Actual Cost − Forecasted Cost| / Forecasted Cost
A score of 1.0 means perfect alignment; lower scores indicate cost overrun or underrun relative to forecast.
D
Decision Right
owner: capability
The formal authority to make a specific type of portfolio decision. Decision rights are allocated by decision type — Gate 1, Gate 2, ratification, exception, reallocation — and held by specific roles (typically the Portfolio Leadership Group for gate and ratification decisions, Value Stream Owners for decisions inside funded guardrails). Making decision rights explicit is part of what Portfolio Governance and Decision-Making produces.
See: Portfolio Governance and Decision-Making · Portfolio Leadership Group
Definition of Done
owner: flow
A team’s explicit agreement on what “done” means — the conditions a work item must satisfy before it is considered complete and part of a potentially releasable increment. Common elements: code reviewed and merged, automated tests passing, monitoring in place, documentation updated. The DoD is a living agreement — it should become more demanding as team capability matures.
See: Team Kanban Flow
Definition of Ready
owner: model
The conditions a work item must meet before it can be pulled into active delivery. At Story level: clear description, acceptance criteria defined, sized, dependencies identified. A story that enters a sprint without meeting the Definition of Ready creates drag for the whole team.
DoD 1 — Ready for Deploy to Prod
owner: flow
First definition of done in the DVS delivery perspective. Implementation complete, integration testing passed, Verification in Stage passed, all acceptance criteria met. The feature is technically ready for production; deployment may be deferred pending feature toggle infrastructure.
DoD 2 — Ready for Release
owner: flow
Second definition of done in the DVS delivery perspective. Feature deployed to production, feature toggle in place where applicable, release decision confirmed. No technical blockers remain.
DoD 3 — Released
owner: flow
Third definition of done in the DVS delivery perspective. Feature available to customers. Benefit hypothesis evaluation can begin.
Delivery capacity
owner: capability
One of two specific forms of capacity at portfolio level (the other is analytical capacity). The capacity of value streams to implement approved initiatives — the teams, competencies, and architectural bandwidth available to build and deliver. Consumed in the Implementing stage of the portfolio flow. Funded as run-rate value-stream capacity through Financial Governance.
See: Capacity · Capacity and Flow Management · Financial Governance
Delivery domain
owner: capability
The downstream portion of the portfolio flow — where approved initiatives are turned into delivered outcomes by development value streams. One of the two prioritization domains (Steyaert, Essential Upstream Kanban); contrasts with the Discovery domain. The delivery domain has its own prioritized list, its own capacity (delivery capacity), and its own intake event (Gate 2 investment decision). Metrics here measure throughput, lead time, and predictability.
See: Initiative Prioritization · Portfolio Kanban Flow
Delivery Organization
owner: model
The set of teams, value streams, and functions responsible for developing and delivering value to customers and the business. Operates at three levels: portfolio, DVS, and team. Distinct from the line organization.
See: Delivery Organization Scope
Delivery System
owner: model
An IT organization treated as a designed system with a defined purpose: developing and operating IT capabilities for external or internal customers. The delivery system is embedded in a larger organization, which is embedded in a broader environment. ASP models this system — its structure, operating principles, and the design choices that determine its effectiveness.
See: Lean-Agile Delivery System
Delivery Value Stream Facilitator (DVF)
owner: role
The program management lead at DVS level. Responsible for planning intervals, system demonstrations, retrospectives, and the overall delivery rhythm of the DVS. Removes impediments that cross team boundaries.
Avoid: RTE, Release Train Engineer (SAFe-specific)
See: DVS Roles
Delivery System Retrospective
owner: practice
A cadence capability — the ability to inspect how the delivery system itself functioned during the planning interval and to identify and commit to improvements. This is the system looking at itself, not at the product it built. Operates at the rhythm of the PI, not at individual flow stages.
Deploying to Production
owner: flow
Stage 9 in the DVS Feature Kanban. The feature is deployed to the production environment — potentially toggled off initially. Should be short; persistent delay indicates pipeline investment is needed.
Delay
owner: thinking
The separation of cause and effect in time within a complex system. A decision made today may not produce observable consequences for months. Delays make learning difficult and intervention dangerous — by the time a problem is visible, its cause is often distant.
Grounded in: Systems Thinking
Deployment Pipeline
owner: thinking
The automated path from a committed code change to running software in production. A well-designed deployment pipeline is fast, repeatable, and safe enough to use on demand. Handoffs between development and operations are replaced by automation.
Grounded in: DevOps Thinking
DevOps Thinking
owner: thinking
The discipline of treating the full delivery pipeline from code to production as a single, continuously optimized system — removing the structural separation between building software and running it. One of the five foundational thinking disciplines in ASP.
See: DevOps Thinking
Discard rate
owner: metric
The proportion of candidates filtered out of the discovery domain before reaching the delivery domain. A high discard rate is a positive signal — it indicates the discovery process is filtering effectively. A low discard rate is the warning sign: it suggests candidates are being committed without adequate evaluation.
See: Initiative Prioritization
Discovery domain
owner: capability
The upstream portion of the portfolio flow — where candidates are matured from idea to investment-ready through analytical work. One of the two prioritization domains (Steyaert, Essential Upstream Kanban); contrasts with the Delivery domain. The discovery domain has its own prioritized list, its own capacity (analytical capacity), and its own intake event (Gate 1 investment decision). Metrics here measure option quality, discard rate, and discovery time — not throughput.
See: Initiative Prioritization · Discovery and Business Casing
Discovery Queue
owner: flow
The prioritized queue of initiative candidates that have passed Gate 1 and are awaiting analytical capacity to be matured through Discovery and Business Casing toward Gate 2. Maintained by Initiative Prioritization within the discovery domain.
See: Initiative Prioritization · Portfolio Kanban Flow
Discovery time
owner: metric
How long it takes to mature a candidate from intake to investment-ready in the discovery domain. Distinct from delivery lead time. Useful as a flow indicator for the discovery domain — long discovery times may signal under-capacity or unclear evaluation criteria.
See: Initiative Prioritization
Domain Requirements
owner: model
The stable logic of the domain — business rules that describe how the business works, independent of any specific feature. Features may introduce, modify, or expose a business rule — but the rule is larger than the feature. One of four categories in the requirements domain. Per ADR-003 in meta/DECISIONS.md.
See: Needs and Requirements · Requirements
Development Value Stream (DVS)
owner: model
The organizational construct that delivers features to customers — a stable team of teams with a shared product mission, continuous funding, and clear ownership of an end-to-end delivery capability. A DVS is both a structural unit and the context within which feature flow is measured. ASP’s specific organizational realization of the development value stream concept — see Value Stream for the generic concept.
Not to be confused with the flow itself — the DVS is the organization, feature flow is what moves through it.
SAFe equivalent: Agile Release Train (ART)
DVS Feature Kanban
owner: flow
The visual system used to manage feature flow at the DVS level. Ten stages: Funnel → Exploring → Analyzing → PI Backlog → Committed → Implementing → SIT → Verification in Stage → Deploying to Production → Releasing → Done. WIP limits apply to the active stages.
DVS Flow Metrics
owner: metrics
The metrics framework for measuring feature flow through the DVS Feature Kanban system. Covers 14 feature-level metrics (flow time and WIP age per stage) and 5 DVS-level metrics (flow velocity, flow time, flow load, flow distribution, flow predictability).
See: DVS Flow Metrics
E
Enabler Feature
owner: model
A Feature type that invests in the delivery capability that makes future Business Features possible — architectural runway, infrastructure, platform, compliance, security hardening, technical debt reduction. Not second-class work. Neglecting Enabler Features creates the technical conditions that slow or block Business Feature delivery over time.
See: Feature
Enabler Story
owner: model
A Story type that invests in technical capability — infrastructure, refactoring, test coverage, security hardening, observability. Implements the technical parts of Enabler Features or addresses technical needs identified during functional development.
See: Story
Enterprise Strategy
owner: model
The organization-level direction set above the portfolio. Defines the overarching
direction the portfolio works within. The portfolio does not set enterprise
strategy; it receives it as input and translates it into portfolio-level intent
through Strategic Goal Management.
See: Strategic Goal Management
Enabling Areas
owner: model
Shared specialist functions that support delivery teams across the organization — architecture, quality, CI/CD, UX, and agile enablement. They develop shared principles and provide specialist support. They do not gate or control team decisions.
See: Enabling Areas
Emergence
owner: thinking
The phenomenon where system behavior cannot be predicted from the behavior of individual parts. A team of capable individuals can produce a dysfunctional delivery system. What matters is what emerges from the interactions — not the properties of the parts in isolation.
Grounded in: Systems Thinking
Empirical Process Control
owner: thinking
A process model based on transparency, inspection, and adaptation — rather than defined steps assumed to produce a predictable outcome. You inspect what is actually happening and adapt accordingly. The foundation of Scrum and agile delivery.
Grounded in: Agile Thinking
Exploring
owner: flow
Stage 2 in the DVS Feature Kanban. Where the DVS builds understanding before committing to a solution — investigating technical feasibility, architectural implications, business needs, and customer needs. Output is understanding, not a plan.
Enterprise Architect
owner: role
A portfolio-level role responsible for the architectural vision that spans value streams. Ensures that value stream architectural decisions remain compatible with the long-term technical direction of the enterprise.
See: Portfolio Roles
Environmental Scanning
owner: capability
The capability to monitor signals from outside the organization — market, competitive, technology, regulatory, and organizational — and to interpret what they mean for portfolio direction and investment decisions. The only portfolio capability whose inputs come from outside the system. Operates as a horizontal capability across all four phases of the portfolio flow.
F
Feasibility
owner: capability
The assessment of whether the delivery system can build an initiative within the relevant time horizon. Composed of two distinct system properties: capability (what the system can do structurally) and capacity (what it has available now). A system can have the capability but lack capacity, or have capacity but lack capability — feasibility asks both questions and produces a single judgment.
See: Initiative Prioritization · Capacity and Flow Management
Feature
owner: model
A service that fulfills a stakeholder need. Features are the primary unit of delivery in a DVS — sized to be deliverable by a single DVS within a Program Increment, with a benefit hypothesis and acceptance criteria.
Feature types:
- Business Feature — delivers direct customer value
- Enabler Feature — supports future business functionality (architecture, infrastructure, compliance)
See also: Initiative, Story
Feature Flag
owner: flow
A mechanism that allows a feature to be deployed to production but kept invisible to users until a deliberate release decision is made. Decouples deployment from release — the feature is in production but not yet customer-visible.
Functional Story
owner: model
A Story type that delivers a user-visible behavior. The most common Story type.
See: Story
Feedback Loop
owner: thinking
A mechanism by which outputs of a system are fed back as inputs, influencing future behavior. Reinforcing loops amplify change in both directions. Balancing loops resist change and maintain stability. Understanding which loops are active in a system is more useful than searching for root causes in individual events.
Grounded in: Systems Thinking
Financial Governance
owner: capability
The capability to allocate portfolio investment as stable value-stream capacity within strategic guardrails, and to track how that capacity is used as a continuous signal for portfolio governance. Operates in two halves separated by cadence: setting allocation at the cadence of the planning horizon, and tracking allocation continuously through value-stream burn against run-rate.
See: Financial Governance
Flow
owner: thinking
The movement of work through a delivery system from intake to completion. Flow is optimized when work moves continuously without waiting, accumulation, or unnecessary handoffs.
Flow Time
owner: metrics
The elapsed time for a work item to move from a defined start point to a defined end point. Also called lead time or cycle time depending on where the measurement starts. In ASP, flow time is always defined relative to a specific stage entry point.
Flow Distribution
owner: metrics
The proportion of active work items in each kanban stage at a given point in time. Reveals where work is accumulating and where the system is flowing freely. Uneven distribution is a signal worth investigating.
Flow Load
owner: metrics
The total number of work items currently active in the system (in progress across all stages). High flow load relative to throughput causes longer flow times — a direct expression of Little’s Law.
Flow Predictability
owner: metrics
At DVS level: the percentage of features committed at PI Planning that reached Done.
(Features committed that reached Done / Total features committed) × 100
Target range: 80–100%. Below 70% indicates systemic issues — overcommitment, poor decomposition, or dependency failures. At portfolio level: the median of individual initiative flow predictability scores.
See: DVS Flow Metrics · Portfolio Flow Metrics
Flow Velocity
owner: metrics
The number of work items completed per time period — initiatives per quarter at portfolio level, features per PI at DVS level. The primary measure of throughput capacity at each level. Meaningful as a trend across multiple periods — a single period’s velocity is not significant in isolation.
See: DVS Flow Metrics · Portfolio Flow Metrics
G
Gate 1
owner: flow
The portfolio-level investment decision that admits an initiative candidate from Continuous Sensing into the discovery domain. A relevance filter, not a quality gate — the substantive question is whether the candidate is strategically motivated enough to warrant analytical investment. Decided by the Portfolio Leadership Group based on the Triage Group’s recommendation. A passed Gate 1 places the candidate in the Discovery Queue.
See: Portfolio Kanban Flow · Strategic Relevance Assessment · Triage
Gate 2
owner: flow
The portfolio-level investment decision that admits an approved initiative from the discovery domain into delivery. The substantive criterion is the soundness of the investment hypothesis carried in the Lean Business Case. Decided by the Portfolio Leadership Group. A passed Gate 2 places the initiative in the Delivery Queue, where it waits for delivery capacity to become available.
See: Portfolio Kanban Flow · Discovery and Business Casing · Portfolio Governance and Decision-Making
Governing Requirements
owner: model
External obligations — regulatory, legal, contractual, or organizational policy — that constrain what the system may do and how it must behave. Mandatory: non-compliance carries legal, financial, or reputational consequences. Constrain what needs may propose. One of four categories in the requirements domain. Per ADR-003 in meta/DECISIONS.md.
See: Needs and Requirements · Requirements
H
Hypothesis-Driven Development
owner: thinking
An approach where every significant investment is treated as a testable hypothesis: we believe that building X will produce outcome Y for user Z. The hypothesis is tested with the smallest possible increment that generates real signal. Features that do not produce the expected outcome are adapted or abandoned.
Grounded in: Product Thinking
I
In Progress
owner: flow
Stage 4 in the Team Kanban. Active development — design, implementation, automated testing, security review, and integration. WIP should be explicitly limited. Stories that sit here for multiple days without movement are a signal worth investigating.
See: Team Kanban Flow
Initiative
owner: model
A significant investment requiring portfolio-level governance, scoped to approximately six to eighteen months. An Initiative is a value hypothesis — a statement of what problem is worth solving, what outcome is expected, and what investment is justified to pursue. It is a primary unit of flow through the Portfolio Kanban system, alongside Strategic Initiatives. Sized XS (under 6 months) to XL (over 18 months).
See also: Strategic Initiative, Feature, Story
Initiative Owner
owner: role
A portfolio-level role accountable for a specific Initiative or Strategic Initiative from hypothesis through outcome assessment. Develops the Lean Business Case, monitors progress, and makes the continue, pivot, or stop recommendation as the initiative evolves.
See: Portfolio Roles
Initiative Candidate
owner: model
The information carrier for an idea or need entering the portfolio system. Starts light at intake — title, source, problem statement, classification — and is progressively enriched through Triage, Investigate, and Investment Framing. By Gate 2 the candidate has matured into an approved Initiative. The initiative candidate and the Initiative are the same artifact at different stages of maturity.
See: Needs Capture
Initiative Spend Tracking
owner: capability
The activity of holding each active initiative’s actual cost — its Cost in Progress — against the cost estimate in its Lean Business Case, as a continuous input to continue/pivot/stop judgments. The cost-side of investment hypothesis tracking, distinct from value-side and clarity-side evidence. Owned by Continuous Initiative Validation.
See: Continuous Initiative Validation · Cost in Progress · Lean Business Case
Inspect and Adapt
owner: metrics
A structured review event at the end of a Program Increment where the DVS examines its metrics, identifies systemic impediments, and builds an improvement backlog. The primary cadence point for acting on flow and predictability data.
Intake
owner: flow
The first stage of Continuous Sensing in the Portfolio Kanban — where initiative candidates are received, registered, and held visible until an explicit decision is made. Intake applies two flow policies (Who may submit, What is required) defined in Portfolio Kanban Flow but does not evaluate strategic relevance, value, or feasibility.
See: Needs Capture · Portfolio Kanban Flow
Investigate
owner: flow
The first stage of Continuous Discovery in the Portfolio Kanban — where an initiative is understood deeply enough to be framed as an investment in the next stage. Led by the Initiative Owner. The goal is not to eliminate uncertainty but to reduce it sufficiently for a sound investment decision. Output: sufficient understanding to frame the initiative as an investment.
See: Discovery and Business Casing · Portfolio Kanban Flow
Investment Framing
owner: flow
The second stage of Continuous Discovery in the Portfolio Kanban — where what was learned in Investigate is structured into a form that enables a go/no-go investment decision at Gate 2. Led by the Initiative Owner with the same team that conducted Investigate. Output: the Lean Business Case, ready for Gate 2.
See: Discovery and Business Casing · Portfolio Kanban Flow
Investment decision
owner: capability
A formal portfolio decision to apply capacity — analytical or delivery — to an initiative. At Gate 1, the investment decision is to apply analytical capacity (admitting the initiative to the discovery domain). At Gate 2, the investment decision is to apply delivery capacity (admitting it to the delivery domain). Investment decisions do not commit to delivery dates or earmark capacity for specific durations — they commit to applying the system’s finite capacity.
See: Initiative Prioritization · Portfolio Governance
Investment Mandate
owner: capability
The bounded space within which a role has authority to make decisions without escalation. A Value Stream Owner’s mandate covers decisions inside the value stream’s funded guardrails; an Initiative Owner’s mandate covers decisions inside an approved Lean Business Case’s envelope. Decisions outside mandate become exception decisions handled by the Portfolio Leadership Group. Distinct from decision right (which names the holder) — mandate names the scope.
See: Portfolio Governance and Decision-Making · Decision Right · Financial Governance
K
Kanban
owner: thinking
A method for visualizing and managing flow. A Kanban board makes work visible — what is waiting, what is in progress, and what is done — and uses WIP limits to regulate how much work is active at any time. Kanban is a tool for managing flow, not a delivery methodology in itself.
ASP uses Kanban boards at portfolio level (Portfolio Kanban) and DVS level (Feature Kanban) to visualize initiative and feature flow respectively.
L
Lead Time
owner: metric
The time from when an initiative enters delivery to when it is delivered. A throughput-side metric, distinct from Flow Time (which can apply to any kanban stage). Used in the delivery domain to assess delivery system performance.
See: Portfolio Flow Metrics · Flow Time
Line Organization
owner: model
The organizational structure responsible for people management, professional development, working conditions, and long-term capability building. Provides resources and support to the delivery organization. Does not direct what is built or how delivery teams work.
See: Delivery Organization Scope
Lean Business Case
owner: model
A lightweight investment justification produced for an Initiative or Strategic Initiative — the minimum analysis required to make a sound go/no-go decision at Gate 2. Contains strategic alignment, value hypothesis, solution hypothesis, MVP definition, cost estimate, expected outcomes, and go/no-go criteria. Deliberately brief — its purpose is to support a decision, not to produce a comprehensive plan. Often abbreviated LBC.
See: Initiative · Discovery and Business Casing · Financial Governance
Lean Thinking
owner: thinking
A discipline centered on identifying value from the customer’s perspective and eliminating everything that impedes its continuous flow. One of the five foundational thinking disciplines in ASP.
See: Lean Thinking
Little’s Law
owner: thinking
A mathematical relationship: average flow time = average flow load / average throughput. In practical terms: if you have more work in progress than your system can handle, flow times grow. Reducing WIP is often the fastest way to reduce lead times.
Local Optimization
owner: thinking
Improving the performance of a part of a system at the expense of the whole. The most persistent failure mode in scaled delivery — a team metric that optimizes throughput at the expense of quality, or a governance model that adds oversight at every level. Each locally rational. Globally destructive.
Grounded in: Systems Thinking
LPM (Lean Portfolio Management)
owner: role
The function responsible for strategy, investment funding, and governance at the portfolio level. LPM makes go/no-go decisions on initiatives, manages portfolio flow, and connects organizational strategy to delivery.
M
MVP (Minimum Viable Product)
owner: thinking
The smallest version of a solution that delivers enough value to validate the core hypothesis. An MVP is not a poor-quality product — it is a deliberately scoped delivery designed to generate the fastest possible learning.
N
Needs
owner: model
One of two domains a scaled delivery system responds to. Needs are directional vectors — what stakeholders want the system to deliver. They are consumed when delivered: once a need has been built, it leaves the system as accomplished work. Needs flow through three artifact levels: Initiative at portfolio, Feature at DVS, Story at team. Per ADR-003 in meta/DECISIONS.md; the other domain is requirements (four categories).
See: Needs and Requirements · Needs Hierarchy
NFR (Non-Functional Requirement)
owner: model
See: System Requirements.
O
Operational Requirements
owner: model
Requirements for how the system is operated, maintained, and evolved over its lifetime — monitoring, backup, incident response, deployment constraints, data retention. Ongoing and active for the life of the system. May generate Features but are not themselves Features. One of four categories in the requirements domain. Per ADR-003 in meta/DECISIONS.md.
See: Needs and Requirements · Requirements
OKR (Objectives and Key Results)
owner: practice
A goal-setting framework where qualitative Objectives are paired with quantitative
Key Results that test whether the objective has been realized. In ASP, OKRs are
the typical formulation of outcome goals — the measurable inner part of each
strategic theme. Originated by Andy Grove at Intel; popularized by John Doerr.
See: Outcome Goals · Strategic Goal Management
Option value
owner: capability
The value of having a candidate available as an option for future investment, even if it is not chosen now. Used in the discovery domain to evaluate whether candidates being matured are worth the analytical investment. A candidate with high option value has the potential to deliver significant value if conditions become favorable.
See: Initiative Prioritization
Outcome
owner: thinking
A change in behavior or condition that creates value — users completing a task more efficiently, a process that no longer requires manual intervention, customer retention that improves measurably. Outcomes are what the delivery system exists to produce. Distinct from output.
See also: Output
Outcome Assessment
owner: practice
The activity of evaluating whether a completed initiative delivered the outcomes its Lean Business Case predicted. Tests the value hypothesis against evidence gathered after delivery, producing a status — confirmed, disconfirmed, or inconclusive — and an interpretation of what that result tells us about the underlying belief. Owned by Outcome Measurement and Learning; performed for each initiative that reaches Done.
See: Outcome Measurement and Learning · Lean Business Case
Outcome Evidence
owner: measurement
The observable material on which outcome assessment rests — adoption signals, behavior change, OKR Key Result movement, business metric shifts, qualitative user feedback. Distinct from delivery evidence (which is gathered during implementation) and from flow evidence (which describes movement through the kanban). Outcome evidence is what makes the post-delivery question did it actually work? answerable.
See: Outcome Measurement and Learning · Outcome
Outcome Goal
owner: model
The measurable verification of a strategic theme — typically expressed as an OKR (Objective and Key Results). Outcome goals describe observable changes in the world that confirm a theme is being realized. A theme contains one or more outcome goals; together they form the qualitative-and-measurable pair that anchors portfolio-level direction.
See: Outcome Goals · Strategic Goal Management
Outcome Measurement and Learning
owner: capability
The capability to assess whether completed initiatives delivered their expected outcomes and to synthesize learning across initiatives into intelligence that improves future investment decisions. Stage-specific to Continuous Learning — acts on initiatives that have reached Done, in the Outcome & Learning stage of the Portfolio Kanban. The temporal successor to Continuous Initiative Validation: where CIV asks should we keep going? during delivery, this capability asks did it actually work? after delivery. One of the capabilities that together constitute Agile Portfolio Management.
See: Outcome Measurement and Learning · Continuous Initiative Validation · Strategic Goal Management
Output
owner: thinking
Something delivered — a feature, a system, a report. Outputs are measurable and visible. Delivering outputs that do not produce outcomes is waste, regardless of how well they were executed.
See also: Outcome
P
Platform Team
owner: model
A team type that builds and maintains internal products — platforms, APIs, shared components — with other delivery teams as its customers. Operates as a DevSecOps team in its own right.
See: Team Organization
PI Planning
owner: practice
The planning event that opens each Program Increment. Brings all teams in the DVS together to align on goals, sequence features from the backlog, identify dependencies, and establish the sprint schedule for the PI. The primary synchronization mechanism at DVS level.
PI Backlog
owner: flow
Stage 4 in the DVS Feature Kanban. An actively managed pool of analyzed and approved features, continuously re-prioritized using WSJF, waiting for the next PI Planning event. Distinct from the Committed backlog.
PI (Program Increment)
owner: practice
A fixed-length planning and delivery cycle, typically 8–12 weeks, used to synchronize teams within a DVS. PI Planning is the event that kicks off each PI, bringing all teams together to align on goals and dependencies.
SAFe-specific term. ASP uses PI as the standard cadence reference for DVS-level planning.
Pivot
owner: capability
A portfolio decision to revise an active initiative’s hypothesis — problem framing, solution direction, MVP, or scope — based on evidence that has emerged during delivery. Preserves learning while redirecting investment. Decided by the portfolio leadership group based on the Initiative Owner’s recommendation. One of the three decisions produced by Continuous Initiative Validation.
See: Continuous Initiative Validation · Continue · Stop
Portfolio Flow Metrics
owner: metrics
The metrics framework for measuring initiative flow through the Portfolio Kanban system. Covers 18 initiative-level metrics (flow time, WIP age, cost in progress, predictability) and 10 portfolio-level metrics (flow velocity, flow time, flow load, flow distribution, predictability, economic, and commitment metrics).
Portfolio Management Function
owner: model
The group of people with collective responsibility for investment governance at portfolio level. Makes go/no-go investment decisions, manages initiative flow, and connects organizational strategy to value streams. Operates continuously — not as an occasional committee.
Portfolio Manager
owner: role
Leads the portfolio management function. Manages the portfolio kanban process, facilitates investment decisions, and maintains portfolio visibility.
See: Portfolio Roles
Portfolio Kanban
owner: flow
The visual system used to manage initiative flow at the portfolio level. Stages run from Intake through Triage, Investigate, Investment Framing, Implementing, to Outcome & Learning — organized into four continuous phases: Continuous Sensing, Continuous Discovery, Continuous Delivery, and Continuous Learning. Gate 1 admits a candidate to the discovery domain; Gate 2 admits an approved initiative to delivery.
Portfolio Leadership Group
owner: role
The collective decision-making body of the portfolio management function. Makes go/no-go investment decisions at gate points, sets strategic themes and outcome goals, approves budget allocations, and holds accountability for portfolio-level outcomes. Not a single person — a collective function with the authority and information needed to make sound investment decisions. Distinct from the Portfolio Office (which administers the process) and from individual Initiative Owners.
See: Portfolio Organization · Portfolio Roles
Portfolio Office
owner: model
The portfolio function that administers the governance process — managing the Portfolio Kanban, facilitating decision forums, maintaining portfolio visibility, and conducting intake hygiene. Distinct from the Portfolio Leadership Group (which makes investment decisions) and from individual Initiative Owners. Often led by the Portfolio Manager.
See: Portfolio Organization · Portfolio Roles
Portfolio Roadmap
owner: model
The portfolio-level artefact that makes investment sequencing visible across time, structured as two parallel views: a discovery roadmap showing when each initiative is expected to reach Gate 2, and a delivery roadmap showing when each initiative is expected to be done. The two views manage different capacity constraints (analytical capacity vs delivery capacity) and answer different questions (when can we decide vs when will the outcome be available). Administered by the Portfolio Manager; content is distributed across Strategic Goal Management, Initiative Prioritization, Discovery and Business Casing, Portfolio Dependency Management, Capacity and Flow Management, and Portfolio Governance; major changes are ratified by the Portfolio Leadership Group.
See: Portfolio Roadmap
Portfolio Sync
owner: practice
A periodic forum (typically biweekly or monthly) where the portfolio management function reviews kanban flow health, conducts Lean Business Case checks, and prepares for upcoming PI commitments. Operates between the slower Strategic Portfolio Review cadence and the continuous Portfolio Kanban Review. The Portfolio Leadership Group consumes initiative-level signals here — including burn signals from Financial Governance.
See: Portfolio Ways of Working
Portfolio Vision
owner: model
The medium-term ambition that connects enterprise direction to the initiatives the portfolio chooses to fund. Expresses what the portfolio’s delivery system will look like when it is operating at its intended capability. Vision and strategic themes work together: the vision describes the destination; strategic themes describe the territories the portfolio is moving into to reach it.
See: Strategic Goal Management
Predictability
owner: metrics
A measure of how closely actual outcomes match forecasted outcomes. In flow metrics, predictability is calculated as 1 − |actual − forecast| / forecast. Higher predictability reflects a more stable, well-understood system — not necessarily a faster one.
Product Backlog
owner: flow
The team’s pool of candidate stories — derived from DVS features, plus technical debt items and bug fixes. Not a queue to clear sequentially. A prioritized pool from which work is pulled when capacity is available and the Definition of Ready is met.
See: Team Kanban Flow
Product and Service Team
owner: model
A team type that owns a well-bounded product or service delivering value directly to customers or the business. Works end-to-end with cross-functional competence — development, testing, security, operations, UX.
See: Team Organization
Product Manager (PM)
owner: role
Leads the product management function at DVS level. Owns the roadmap, product vision, and overall prioritization for the value stream. Works closely with the Delivery Value Stream Facilitator on capacity and priority alignment.
See: DVS Roles
Product Owner (PO)
owner: role
Maintains and prioritizes the team backlog. Ensures the team works toward business and customer goals. Participates in DVS-level planning and connects team delivery to the value stream’s strategic direction.
See: Team Roles · DVS Roles
Product Thinking
owner: thinking
The shift from a project model — where success means delivering scope — to an outcome model where success means creating measurable value for users and the organization. One of the five foundational thinking disciplines in ASP.
See: Product Thinking
R
Refinement
owner: flow
Stage 2 in the Team Kanban. Stories are analyzed, clarified, and prepared for sprint selection. Continuous — not a single event. Ensures the top of the backlog is always ready to be pulled. A story that enters a sprint without passing through Refinement creates drag for the whole team.
See: Team Kanban Flow
Releasing
owner: flow
Stage 10 in the DVS Feature Kanban. The feature is made visible to customers — incrementally or all at once. Distinct from Deploying: a feature can be deployed to production but not yet released. The benefit hypothesis is evaluated at this stage.
Replenishment Meeting
owner: capability
The cyclic forum where the priority order of initiatives is deliberately reviewed and refreshed (Anderson, Kanban, 2010). Typically held quarterly at portfolio level. Between Replenishment Meetings, the order may be adjusted in response to material change but is not continuously renegotiated — the cyclic discipline gives the system stability and avoids churn from every new piece of information.
See: Initiative Prioritization · Portfolio Ways of Working
Requirements
owner: model
One of two domains a scaled delivery system responds to. Requirements are always-active constraints — rules, policies, standards, and obligations that shape work continuously. Not consumed when delivered; they persist. The domain has four categories: Domain Requirements (business rules), System Requirements (NFRs), Governing Requirements (external obligations), Operational Requirements (operational lifecycle). Per ADR-003 in meta/DECISIONS.md; the other domain is needs.
S
Strategic Initiative
owner: model
A multi-year investment decision requiring portfolio-level governance. A Strategic Initiative is a value hypothesis at multi-year scale — it flows through the Portfolio Kanban alongside Initiatives but its primary output from Continuous Discovery is the breakdown into Initiatives, each with their own Lean Business Case and go/no-go decision. Sized S (1.5–2 years), M (2–3 years), L (3–5 years).
See also: Initiative, Portfolio Kanban Flow
Strategic Portfolio Review
owner: practice
A periodic forum (typically per PI or quarterly) where the portfolio management function steps back from individual initiative decisions and reviews the portfolio as a whole — checking strategic alignment, portfolio health, capacity allocation, consuming the synthesis from Environmental Scanning, and performing outcome assessment for initiatives that have reached Done. The slowest cadence in the portfolio governance rhythm; complements the more frequent Portfolio Sync.
See: Portfolio Ways of Working
Strategic Theme
owner: model
A strategic area — a territory the organization has chosen to invest in. Themes are qualitative in description but contain measurable verification through one or more outcome goals expressed as OKRs. Themes filter what enters the portfolio; outcome goals test whether what was delivered has mattered. The structure follows Kaplan & Norton’s Balanced Scorecard pattern of strategic areas with measurable outcomes nested inside.
See: Strategic Goal Management · Outcome Goals
Stock
owner: thinking
Something in a system that accumulates or depletes over time — capacity, knowledge, trust, technical debt. Stocks change gradually through flows. Managing flow without understanding the stocks it moves through produces unpredictable results.
Grounded in: Systems Thinking
Stop
owner: capability
A portfolio decision to discontinue an active initiative because its hypothesis is invalidated or because capacity is better invested elsewhere. Forward-looking — sunk cost is not a valid input. Produces learning that flows into how future initiatives in the same domain are framed. One of the three decisions produced by Continuous Initiative Validation.
See: Continuous Initiative Validation · Continue · Pivot
Story
owner: model
The smallest unit of delivery — a piece of work a team can complete within a single iteration. Stories are derived from Features and carry just enough detail for a team to build and test a solution.
See also: Feature, Initiative
System Demo
owner: practice
A regular event (typically end of each iteration or PI) where teams demonstrate integrated, working software to stakeholders. The system demo is a synchronization and feedback mechanism — it surfaces integration issues and creates a regular cadence of stakeholder visibility.
Spike
owner: model
A time-boxed investigation into an unknown — used when the team needs to reduce uncertainty before committing to implementation. Produces knowledge, not software: its output is a decision or recommendation. Spikes should be rare; routine use signals insufficient refinement or underinvestment in domain understanding.
See: Story
Strategic Goal Management
owner: capability
The capability to translate organizational strategy into portfolio-level
direction — vision, strategic themes, and outcome goals — and to maintain
that direction as a live steering mechanism for investment and delivery
decisions. Operates in two halves separated by cadence: setting direction
at the start of a planning horizon, and maintaining direction continuously
as strategy, environment, and delivery evidence evolve.
See: Strategic Goal Management · Strategic Theme · Outcome Goal
Sprint
owner: flow
A fixed-length delivery cycle at team level — typically one or two weeks. The team selects stories from the Product Backlog, works toward a Sprint Goal, and produces a potentially releasable increment. Also referred to as Iteration.
Sprint Backlog
owner: flow
Stage 3 in the Team Kanban. Stories selected for the current sprint, framed by a Sprint Goal. The team’s commitment for the cycle.
See: Team Kanban Flow
Sprint Goal
owner: flow
The single objective a team commits to achieving in a sprint. Frames the sprint backlog — individual stories are in service of the goal, not independent items to tick off. A sprint without a goal is a list of tasks, not a commitment.
See: Team Kanban Flow
Security Lead
owner: role
A DVS-level role that integrates security considerations into product management decisions. Ensures that secure-by-design is a product priority.
See: DVS Roles
Size
owner: capability
How much delivery system capacity an initiative claims, expressed in calendar time and relative magnitude. At portfolio level, size uses T-shirt sizing anchored to delivery horizons (XS, S, M, L, XL) — not story points or hours. Size matters for two reasons: it determines what the initiative costs in capacity terms, and it determines whether initiatives are comparable to each other for relative prioritization. Striving for jobs in similar size ranges is a system-design choice, not a prioritization rule.
See: Initiative · Initiative Prioritization
Synchronization
owner: principle
The alignment of multiple teams and value streams at defined integration points. Synchronization ensures that teams working in parallel remain coherent — their outputs fit together, their priorities are aligned, their dependencies are visible. Works together with cadence.
See: Cadence and Synchronization
System Requirements
owner: model
Constraints on how the system behaves — performance, security, availability, scalability, compliance with technical standards. Cross-cutting: they apply to all features, not individual ones. Long-lived. Also referred to as Non-Functional Requirements (NFR). One of four categories in the requirements domain. Per ADR-003 in meta/DECISIONS.md.
See: Needs and Requirements · Requirements
System / Solution Architect
owner: role
Owns reference architecture and long-term technical direction for the value stream. Ensures architectural coherence across teams. Operates in both product management and program management contexts at DVS level.
See: DVS Roles
System Integration Test (SIT)
owner: flow
Stage 7 in the DVS Feature Kanban. Verifies that features work correctly together in a shared integration environment — not just in isolation within a single team’s environment.
Systems Thinking
owner: thinking
The discipline of understanding organizations as complex, interconnected systems where cause and effect are often separated in time and space — and where local optimization routinely destroys global performance. The foundational thinking discipline in ASP.
See: Systems Thinking
T
Traceability
owner: model
The explicit connection between artifacts at different levels of the needs hierarchy — from Story to Feature to Initiative. Makes the delivery system coherent: when a team asks “why are we building this?”, traceability provides the answer. Business value is established at Initiative level and inherited downward.
See: Needs Hierarchy
Technical Debt
owner: principle
The accumulated cost of shortcuts, deferred design decisions, and quality trade-offs in a codebase or delivery system. Technical debt is a stock — it builds up gradually and erodes delivery capacity over time. Addressed through deliberate investment in refactoring, automation, and architectural improvement.
Throughput
owner: metric
The rate at which initiatives complete delivery in the delivery domain — how many initiatives delivered per unit of time. A delivery-domain metric. Distinct from Discovery domain metrics, which measure option quality rather than throughput.
Transparency
owner: principle
The condition where information about work, decisions, problems, and progress is available to those who need it — without requiring requests or navigating barriers. A prerequisite for effective collaboration and evidence-based decision-making.
See: Transparency and Collaboration
Triage
owner: flow
The stage in Continuous Sensing where registered initiative candidates are assessed for strategic relevance before Gate 1. Operates rapidly — produces a recommendation, not an analysis. Triage outcomes: proceed to Gate 1, park for later reconsideration, or stop.
See: Strategic Relevance Assessment · Portfolio Kanban Flow
TTM (Time to Market)
owner: metrics
Total elapsed flow time from when a work item enters active consideration to when it is done. In ASP, TTM for initiatives starts when the initiative enters Triage; TTM for features starts when the feature enters Analyzing.
U
UX / Design Lead
owner: role
Coordinates user experience across the value stream. Maintains the design system at DVS level and ensures consistency in how users experience the product across teams.
See: DVS Roles
V
Verification in Stage
owner: flow
Stage 8 in the DVS Feature Kanban. The feature is deployed to a production-like staging environment and verified against its defined acceptance criteria. The final confirmation that all pull policy criteria are met before production deployment.
Value and Outcomes Focus
owner: principle
The practice of evaluating all decisions and activities against real value and measurable outcomes — not activity, output, or technical delivery without business context. One of the 12 ASP Principles.
Value-Based Prioritization
owner: principle
Prioritization grounded in value types (customer, business, strategic), cost of delay, and economic thinking — rather than politics, recency, or loudest voice. One of the 12 ASP Principles.
See: Value-Based Prioritization
Value Stream Owner
owner: role
Accountable for a development value stream’s outcomes and budget. Participates in portfolio decisions that affect the value stream’s funding or strategic direction.
See: Portfolio Roles
Value Stream
owner: thinking
The sequence of steps that deliver value to a customer — from initial request to realized outcome. Value streams can be operational (fulfilling an existing service) or development (building new capability). ASP focuses on development value streams — see Development Value Stream for ASP’s specific organizational realization of this concept.
Value Stream Funding
owner: model
The mechanism through which the portfolio funds development value streams as stable capacity — run-rate funding allocated against the planning horizon, rather than project-specific budgets approved per initiative. The value stream draws against its allocation as work flows through; new initiatives consume capacity that has already been funded. Grounded in Bogsnes (Beyond Budgeting) and Kersten (Project to Product).
See: Financial Governance
Verification
owner: flow
Stage 5 in the Team Kanban. The story is verified against its acceptance criteria. In a mature team, the majority is automated and embedded in the pipeline. Manual exploratory testing addresses what automation cannot reach. Not a handoff to a separate QA function — the team owns quality.
See: Team Kanban Flow
W
Waste
owner: thinking
Any activity that consumes resources without creating value. Lean identifies seven classic waste types from manufacturing — all with direct equivalents in knowledge work. The dominant wastes in delivery organizations are waiting, partially done work, and task switching.
Grounded in: Lean Thinking
WIP Age
owner: metrics
How long a work item has been in its current kanban stage. Used to identify stalled work before it becomes a blocker. Distinct from Flow Time — WIP Age is a current measure (how long has this item been here now?), while Flow Time is a completed measure (how long did items take to move through?).
See: DVS Flow Metrics · Portfolio Flow Metrics
WIP (Work in Progress)
owner: thinking
Work that has been started but not yet completed. High WIP is the primary cause of long flow times. WIP limits — caps on how much work can be active in a given stage — are the primary mechanism for improving flow.
WIP Limit
owner: flow
A cap on how much work can be active in a given kanban stage at any one time. The primary mechanism for improving flow. When a stage is at its WIP limit, no new work enters until existing work moves forward — making bottlenecks visible and forcing resolution rather than accumulation.
WSJF (Weighted Shortest Job First)
owner: thinking
A prioritization method that sequences work to maximize economic value delivered over time. WSJF score = Cost of Delay / Job Duration. Work with high cost of delay and short duration is prioritized first.
SAFe-specific calculation method. The underlying principle — prioritize by value per unit of time — is a general lean economics concept.