Ein Increment (Produktinkrement) ist das in sich nutzbare, integrierte Arbeitsergebnis einer Iteration, das auf allen bisherigen Inkrementen aufbaut. Es umfasst die Summe aller seit Produktbeginn „fertigen“ (Definition of Done) Product-Backlog-Einträge und befindet sich in einem potenziell auslieferbaren Zustand.
In Scrum entsteht mindestens ein Increment pro Sprint. In SAFe entstehen Team-Inkremente pro Iteration; auf ART-Ebene ergibt die Integration dieser Team-Inkremente das System-Inkrement. Über ein Program Increment (PI) hinweg (typisch 8–12 Wochen) liefert ein ART inkrementellen Wert in Form funktionierender Software oder Systeme; sichtbar u. a. in System Demos und beim Inspect & Adapt.
Praktische Relevanz
- Wertfokus: Jedes Increment schafft konkreten Kundennutzen und reduziert „Big-Bang-Risiken“.
- Qualität eingebaut: Die konsequente Definition of Done erzwingt integrierte, getestete, dokumentierte Ergebnisse – keine Restarbeiten.
- Schnelles Lernen: Regelmäßige Nutzertests ermöglichen frühes Feedback und Kurskorrekturen.
- Transparenz & Steuerbarkeit: Inkremente sind harte Inspektionspunkte für Fortschritt, Risiko und Wirtschaftlichkeit.
- Skalierbarkeit: In SAFe synchronisiert die Kadenz Teams und minimiert Integrationsüberraschungen.
Praktische Beispiele
Scrum – Digitales Kundenportal
Ein Energieversorger erneuert sein Portal. Alle zwei Wochen entsteht ein Increment mit echtem Kundennutzen.
Artefakt: Team-DoD mit Testabdeckung ≥ 80 %, E2E-Tests grün, Security-Scan ohne kritische Findings, Release Notes gepflegt.
SAFe/ART – Eingebettetes System
Ein ART mit sechs Teams integriert alle zwei Wochen am Prüfstand.
Artefakt: ART-Checkliste mit Safety-Suite grün, Telemetrie aktiv, Recovery-Pfad getestet.
SAFe – Plattform & Produkt
Plattform-ART liefert APIs, Produkt-ART integriert Workflows.
Artefakt: Contract-Test-Skeleton mit OpenAPI-Spezifikation.
Regulierte Domäne
Compliance-Artefakte werden pro Increment integriert.
Artefakt: Aktualisierte DPIA, Audit-Trail-Events, IAM-Berechtigungen, Security-Testreports.
Transformation Increment (TI)
Quartalsweise Transformation mit klaren Outcomes.
Artefakt: TI-Review-Board mit Zielen, Baseline, Ergebnissen und Next Actions.
Hardware-nahe Entwicklung (Automotive/MedTech/Industrie)
Auch Hardware-Teams liefern in Iterationen Inkremente – funktionale Prototypen oder Baugruppen, die integriert und getestet werden können.
Artefakt: Hardware-DoD mit Baugruppe aufgebaut, Schnittstellen geprüft, Belastungstests bestanden, Sicherheitsnachweise erstellt, Daten im PDM-System
Weitere Beispiele:
- Automotive: Steuergeräte-Prototyp inkl. Firmware alle 3 Wochen; getestet im HiL (Hardware-in-the-Loop).
- MedTech: Iterative Inkremente eines Diagnostikgeräts, mit ISO-13485-Dokumentation.
- Industrie/Robotik: Schrittweise funktionsfähige Baugruppen (z. B. Motorsteuerung, Sensorsysteme), die in jeder Iteration integriert werden.
Umsetzung in der Praxis
- DoD verbindlich: Teams definieren überprüfbare Kriterien, auf ART-Ebene kommen Integration, Compliance und Betriebsfähigkeit hinzu.
- Vertikale Schnitte: Nur Ende-zu-Ende-Slices schaffen echten Wert.
- CI/CD: Jeder Commit potenziell releasbar, Automatisierung auch für Hardware-Simulationen und Prüfstände.
- Systemische Integration: Regelmäßige System Demos verhindern Integrationsstaus.
- Hardware-Inkremente: Prototyp-Stufen klar definieren („Lab Sample → Proto A → Proto B → Pilotserie“).
- Operational Readiness: Monitoring, Alerting und Runbooks gehören zur Definition of Done.
Anti-Patterns
- Demo-ware statt DoD: Es werden nur Oberflächen oder Mock-ups gezeigt, ohne Tests, Dokumentation oder Betriebsfähigkeit. Kurzfristig überzeugend, langfristig wertlos.
- Schichten-Inkremente: Teams liefern „nur Datenbank“ oder „nur Frontend“. Kein Kundennutzen, Integrationsprobleme am Ende.
- Späte Großintegration: Integration erfolgt erst am PI-Ende. Fehlerlawinen, Zeitdruck und Qualitätsprobleme sind die Folge.
- DoD schwammig oder verhandelbar: Wenn „fertig“ nicht überprüfbar ist, entstehen technische Schulden. Unterschiedliche DoDs zwischen Teams ohne Abstimmung machen Integration unmöglich.
- Überladung des Inkrements: Zu viele Stories in ein Increment gepresst → Kontextwechsel, Qualitätsprobleme, Verzögerungen.
- Keine System Demos: Teams arbeiten isoliert, das integrierte Produkt bleibt zu lange unsichtbar.
- Fehlende NFRs: Performance, Sicherheit oder Betriebsaspekte sind nicht Teil der DoD → Produkt ist zwar funktional, aber nicht nutzbar oder compliant.
- Nur Simulation in Hardware-Projekten: Inkremente bestehen aus CAD-Daten oder Mock-ups ohne physische Tests. Risiken bleiben verborgen, reale Integrationsprobleme treten zu spät auf.
- Fokus auf Output statt Outcome: Teams liefern „fertige Stories“ oder Prototypen, ohne den Geschäftswert oder Nutzbarkeit zu prüfen.
CALADE-Sichtweise
Wir sehen Inkremente als Taktgeber für Wert, Lernen und Qualität – nicht nur in Software, sondern auch in Hardware- und Transformationsprojekten. Mit Transformation Increments (TI) liefern wir vierteljährlich sichtbare Ergebnisse (Policies, Prozesse, Pilotprojekte), machen Fortschritt messbar und schaffen eine adaptive Steuerung. In Hardware-Umgebungen setzen wir auf iteratives Prototyping mit klarer DoD, um Risiken früh sichtbar zu machen und Fachdisziplinen (Mechanik, Elektronik, Software, Compliance) zu verzahnen.
Verwandte Begriffe
- Definition of Done (DoD) – verbindliche Qualitätskriterien
- System Demo (SAFe) – Demonstration des System-Inkrements
- Program Increment (PI) – Zeitfenster für inkrementellen Wert
- Incremental Delivery – Häufige, kleine Releases
- Enabler (SAFe) – Technische/architektonische Arbeiten für Lieferfähigkeit
- Non-Functional Requirements (NFRs) – Qualitätsanforderungen
← zurück zur Übersicht