Increment

Definition

Ein Increment ist ein konkreter Fortschritt in Richtung des Product Goals. Es umfasst die Summe aller Product-Backlog-Einträge, die während eines Sprints abgeschlossen wurden, zusammen mit dem Wert aller vorherigen Increments. Jedes Increment muss nutzbar sein und der Definition of Done des Scrum-Teams entsprechen. Innerhalb eines Sprints können mehrere Increments entstehen.

Warum ist das Inkrement wichtig?

Das Increment macht den Fortschritt am Produkt sofort sichtbar und überprüfbar. Es sorgt dafür, dass regelmäßig werthaltige Ergebnisse entstehen und stärkt das Vertrauen von Stakeholdern. Durch den Fokus auf potenziell auslieferbare Funktionalität verringert es Risiken, fördert Agilität und schafft kontinuierliche Möglichkeiten für Feedback und Anpassung.

Das Increment muss sich am Ende jedes Sprints in einem auslieferbaren Zustand befinden – eine tatsächliche Auslieferung ist jedoch nicht zwingend erforderlich.

Wann & wie es verwendet wird

Am Ende jedes Sprints sollte das Scrum-Team mindestens ein nutzbares Increment erstellt haben, das der Definition of Done entspricht. Es wird während des Sprint Reviews überprüft, wobei Stakeholder Feedback geben.

Increments können so oft veröffentlicht werden, wie es der Product Owner entscheidet – mitunter sogar während eines laufenden Sprints, wenn das Team Continuous Deployment ermöglicht.

Wesentliche Merkmale eines Increments:

  • Nutzbar und testbar
  • Entspricht der Definition of Done
  • Unterstützt Inspektion und Anpassung
  • Kann veröffentlicht werden (auch wenn nicht sofort)

Beispiel aus der Praxis

Ein Team, das an einem Bezahlsystem arbeitet, entwickelt während des Sprints die neue Funktion „Gespeicherte Karten“. Sie wird vollständig integriert, besteht alle automatisierten und manuellen Tests und erfüllt die internen Sicherheitsstandards. Obwohl der Product Owner beschließt, sie erst im nächsten Release-Zyklus auszuliefern, ist sie produktionsreif – und somit ein gültiges Increment.

Häufige Fallstricke oder Missverständnisse

  • Unvollständige Increments: Arbeit, die der Definition of Done nicht entspricht, gilt nicht als echtes Increment.
  • Increment mit „Release“ verwechseln: Ein Increment muss auslieferbar sein, muss aber nicht in jedem Sprint veröffentlicht werden.
  • Mehrere unfertige Features: Halbfertige Arbeiten im Code ohne klares Increment gefährden Qualität und Transparenz.
  • Integration aufschieben: Wenn Integration und Tests verzögert werden, verkleinert sich der Feedback-Zyklus und das Risiko steigt.