Capabilities sind ein Work-Item-Typ im Scaled Agile Framework (SAFe) auf der Solution-Ebene. Sie beschreiben eine größere, über mehrere ARTs (Agile Release Trains) hinweggehende Geschäftsfähigkeit, die typischerweise mehrere Program Increments (PIs) zur Umsetzung benötigt. Capabilities liegen im Solution Backlog und werden in kleinere Features heruntergebrochen, die wiederum in den ART-Backlogs landen. Damit bilden Capabilities die Brücke zwischen Portfolio-Epics und ART-nahen Features.
Praxisbezug
- Einordnung im SAFe-Stack:
- Epics (Portfolio-Ebene) → Capabilities (Solution-Ebene) → Features (ART-Ebene) → Stories (Team-Ebene).
- Abstraktionsgrad: Capabilities sind größer und strategischer als Features, jedoch konkreter als Portfolio-Epics.
- Wertorientierung: Jede Capability wird über Benefit Hypotheses und Acceptance Criteria beschrieben, um sicherzustellen, dass sie einen klaren Kundennutzen erzeugt.
- Schnittstellen: Capabilities sind Enabler für mehrere ARTs und werden im Solution Kanban von Solution Management priorisiert. Solution Train Engineer (STE) und Solution Architect/Engineering spielen dabei eine zentrale Rolle, um Koordination, Architektur-Alignment und Integration sicherzustellen.
Typische Missverständnisse
- „Capabilities sind nur große Features“ – falsch. Sie sind geschäftsorientiert beschrieben und müssen einen klaren Outcome adressieren.
- „Capabilities gelten nur für IT“ – nein. Sie umfassen auch fachliche, organisatorische oder regulatorische Anforderungen.
- „Man braucht immer die Solution-Ebene“ – nicht jedes Unternehmen benötigt Solution-Trains. Capabilities kommen nur dort zum Einsatz, wo Komplexität und mehrere ARTs dies rechtfertigen.
- „Capabilities ersetzen Epics“ – Epics bleiben auf Portfolioebene relevant; Capabilities sind abgeleitete Lösungselemente.
Relevanz für Organisationen
Capabilities schaffen Transparenz und Steuerbarkeit in komplexen Wertströmen:
- Sie helfen, Alignment über mehrere ARTs sicherzustellen.
-Sie machen Abhängigkeiten sichtbar und strukturieren die Arbeit auf einer lösungsorientierten Ebene.
- Sie ermöglichen, den Wertfluss zwischen strategischen Epics und der Umsetzung durch ARTs nachzuvollziehen.
- Sie sind besonders relevant in Branchen mit komplexen cyber-physischen Systemen (z. B. Automotive, Aerospace, Telekommunikation, Defence).
Beispiel aus der Praxis
Ein Automotive-Unternehmen arbeitete mit mehreren ARTs an einer integrierten Fahrerassistenzlösung. Capabilities wurden u. a. definiert als:
- „Adaptive Cruise Control mit OTA-Update-Fähigkeit“
- „Integration von Radar- und Kameradaten für Spurhaltefunktionen“
Diese Capabilities wurden in Features zerlegt und an unterschiedliche ARTs verteilt (z. B. Hardware-nahe Teams, Plattformteams, UX-Teams). Durch die Capability-Logik konnte das Unternehmen abhängigkeitsübergreifend planen und liefern, während die strategische Sicht aufrechterhalten blieb.
Strategien & Best Practices
A. Wirtschaftlich beschreiben
Jede Capability enthält eine Benefit Hypothesis und Akzeptanzkriterien.
Beschreibungen müssen nutzer- und geschäftsorientiert sein, nicht nur technisch.
B. Angemessene Granularität
Capabilities dürfen nicht zu groß (Epic-ähnlich) oder zu klein (Feature-ähnlich) sein.
Faustregel: größer als Features, kleiner als Epics, mit einer typischen Umsetzungsdauer von mehreren PIs.
C. Abhängigkeiten steuern
Capabilities erfordern koordiniertes Refinement durch mehrere ARTs.
Das Solution Kanban dient als zentrales Steuerungssystem.
D. Balance zwischen Business und Enabler Capabilities
Neben Business Capabilities sind Enabler Capabilities essenziell, z. B. für Architektur, Infrastruktur oder regulatorische Anforderungen.
E. Lean Budget Guardrails
Capabilities sind wichtiger Input für Lean Budgets und Guardrails, da sie Investitionen in Lösungen konkretisieren.
7. Typische Stolperfallen
„Capabilities als Container für alles“ – Verwässerung führt zu unklarem Backlog.
Übertechnisierung – Capabilities dürfen nicht nur technische Deliverables sein, sondern müssen Outcomes adressieren.
Fehlende Priorisierung – ohne stringente Steuerung durch Solution Management, STE und Solution Architect verliert das Backlog seine Wirkung.
Zu große Capabilities – wenn sie Epics ähneln, sind sie kaum plan- und steuerbar.
So arbeiten gute Coaches (konkret)
Solution-Kanban aufsetzen und mit Portfolio-Epics verknüpfen.
Capability-Workshops mit Business, Technik, STE und Solution Architect durchführen.
Backlog-Refinement über ART-Grenzen hinweg orchestrieren.
Outcome-Fokus schärfen: Capabilities müssen mit klaren Hypothesen und messbaren Ergebnissen begründet werden.
CALADE-Perspektive
In großen Transformationsprogrammen erleben wir oft, dass Organisationen zwischen Portfolio-Initiativen und ART-Umsetzung einen blinden Fleck haben. Capabilities schließen diese Lücke. CALADE unterstützt Kunden dabei,
- den richtigen Schnitt von Capabilities zu finden,
- das Solution Kanban und die Priorisierungsmechanismen aufzubauen,
- Führungskräfte, STEs und Solution Architects durch Training und Coaching zu befähigen,
- bei Bedarf erfahrene STEs und Solution-Architekten einzusetzen, um die Arbeit nachhaltig im Betrieb zu verankern.
So entsteht ein stabiler Brückenschlag zwischen Strategie, Solution-Ebene und ARTs.
Weiterführende Begriffe
- Epics (Portfolio-Ebene)
- Features (ART-Ebene)
- Stories (Team-Ebene)
- Solution Kanban
- Solution Train Engineer (STE)
- Solution Architect/Engineering
- Lean Budgets & Guardrails
← zurück zur Übersicht