Capabilities are a work item type in the Scaled Agile Framework (SAFe) at the solution level. They describe a larger business capability that spans multiple ARTs (Agile Release Trains) and typically requires several Program Increments (PIs) to implement. Capabilities are located in the solution backlog and are broken down into smaller features, which in turn end up in the ART backlogs. Capabilities thus form the bridge between portfolio epics and ART-related features.
Practical relevance
• Classification in the SAFe stack:
• Epics (portfolio level) → Capabilities (solution level) → Features (ART level) → Stories (team level).
• Level of abstraction: Capabilities are larger and more strategic than features, but more concrete than portfolio epics.
• Value orientation: Each capability is described using benefit hypotheses and acceptance criteria to ensure that it generates clear customer value.
• Interfaces: Capabilities are enablers for multiple ARTs and are prioritized in the Solution Kanban by Solution Management. Solution Train Engineer (STE) and Solution Architect/Engineering play a central role in ensuring coordination, architecture alignment, and integration.
Typical misunderstandings
• "Capabilities are just big features" – wrong. They are described in a business-oriented way and must address a clear outcome.
• "Capabilities only apply to IT" – no. They also include technical, organizational, or regulatory requirements.
• "You always need the solution level" – not every company needs solution trains. Capabilities are only used where complexity and multiple ARTs justify them.
• "Capabilities replace epics" – epics remain relevant at the portfolio level; capabilities are derived solution elements.
Relevance for organizations
Capabilities create transparency and controllability in complex value streams:
• They help ensure alignment across multiple ARTs.
• They make dependencies visible and structure work at a solution-oriented level.
• They make it possible to track the flow of value between strategic epics and implementation by ARTs.
• They are particularly relevant in industries with complex cyber-physical systems (e.g., automotive, aerospace, telecommunications, defense).
Practical example
An automotive company worked with several ARTs on an integrated driver assistance solution. Capabilities were defined as follows:
• "Adaptive cruise control with OTA update capability"
• "Integration of radar and camera data for lane keeping functions"
These capabilities were broken down into features and distributed to different ARTs (e.g., hardware-related teams, platform teams, UX teams). The capability logic enabled the company to plan and deliver across dependencies while maintaining a strategic view.
Strategies & Best Practices
A. Describe economically
• Each capability includes a benefit hypothesis and acceptance criteria.
• Descriptions must be user- and business-oriented, not just technical.
B. Appropriate granularity
• Capabilities must not be too large (epic-like) or too small (feature-like).
• Rule of thumb: larger than features, smaller than epics, with a typical implementation time of several PIs.
C. Control dependencies
• Capabilities require coordinated refinement across multiple ARTs.
• The Solution Kanban serves as the central control system.
D. Balance between business and enabler capabilities
• In addition to business capabilities, enabler capabilities are essential, e.g., for architecture, infrastructure, or regulatory requirements.
E. Lean budget guardrails
• Capabilities are important inputs for lean budgets and guardrails, as they specify investments in solutions.
Typical pitfalls
• "Capabilities as a container for everything" – dilution leads to an unclear backlog.
• Over-technologization – Capabilities must not only be technical deliverables, but must also address outcomes.
• Lack of prioritization – without stringent control by solution management, STE, and solution architects, the backlog loses its effectiveness.
• Capabilities that are too large – if they resemble epics, they are difficult to plan and control.
How good coaches work (in concrete terms)
• Set up Solution Kanban and link it to portfolio epics.
• Conduct capability workshops with business, technology, STE, and solution architects.
• Orchestrate backlog refinement across ART boundaries.
• Sharpen the focus on outcomes: Capabilities must be justified with clear hypotheses and measurable results.
CALADE perspective
In large transformation programs, we often see that organizations have a blind spot between portfolio initiatives and ART implementation. Capabilities close this gap. CALADE supports customers in
• find the right mix of capabilities,
• build the solution Kanban and prioritization mechanisms,
• empowering managers, STEs, and solution architects through training and coaching,
• deploy experienced STEs and solution architects as needed to anchor the work sustainably in operations.
This creates a stable bridge between strategy, the solution level, and ARTs.
Related terms
• Epics (portfolio level)
• Features (ART level)
• Stories (team level)
• Solution Kanban
• Solution Train Engineer (STE)
• Solution Architect/Engineering
• Lean Budgets & Guardrails
← back to list