Was ist ein Increment?

Das Increment ist – neben dem Product Backlog und dem Sprint Backlog – eines der drei Scrum Artefakte. Es stellt Transparenz über den aktuellen Zustand Deines Produktes her und wird in jedem Sprint um weitere Increments erweitert. Darüber hinaus ist das Increment immer verwendbar, um Nutzen für Deine Kunden und User zu stiften.

Im Scrum Guide heißt es deshalb über das Increment:

Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.

Im Wiktionary von Wikipedia findest im entsprechenden Eintrag beim Punkt Bedeutung folgende Information: Betrag, um den eine Größe zunimmt. Das ist ziemlich nichtssagend, wie ich finde. Auch der Ursprung aus dem Lateinischen (incrementare bedeutet vergrößern) bringt uns noch nicht so wirklich weiter.

Deshalb möchte ich es hier mit einer eigenen Definition von Increment versuchen:

Und jedes Mal, wenn Du einen neuen (fertigen) Würfel hinzufügst, entsteht dadurch ein erweiterter (fertiger) großer Würfel.

Vielleicht fragst Du Dich, warum Scrum so viel Wert auf ein fertiges und nutzbares Increment legt. Nun, dafür gibt es zwei wichtige Gründe. Erstens entsteht nur durch ein Increment ausreichend Transparenz. Und zweitens erzeugt ein Increment kontinuierlich neuen Nutzen für Deine Kunden.

Wenn der Kontext, in dem Du Dich mit Deinem Produkt bewegst, durch eine hohe Komplexität gekennzeichnet ist, dann ist es wichtig, möglichst viel Transparenz zu erzeugen. Diese Transparenz ist natürlich dann am höchsten, wenn ein (Software)-Produkt im Live-Betrieb genutzt wird. Je genauere Informationen Du besitzt, desto besser bist Du in der Lage, Entscheidungen zu treffen und Deinen aktuellen Plan anzupassen.

Im Grunde geht es dabei um Fragen wie diese:

Die entstehende Transparenz sorgt darüber hinaus für eine Risikominimierung. Mit einem (wirklich) fertigen und nutzbaren Increment bist Du in der Lage Fehler und Probleme frühzeitig zu entdecken oder kannst schnell herausfinden, ob Dein neustes Feature wirklich Nutzen für Kunden stiftet (oder nicht).

Der zweite Aspekt, der für eine inkrementelle Produktentwicklung spricht, ist die Möglichkeit, Deine Kunden und Nutzer regelmäßig mit neuen Funktionen zu versorgen. Ein Increment ermöglicht es Dir also, nach jedem Sprint neue Funktionen auszuliefern und nicht erst am Ende einer zweijährigen Entwicklungsphase.

Natürlich ist dieser neue Nutzen nicht außerordentlich hoch, wenn Du Increments in zweiwöchigen Iterationen auslieferst. Aber viele kleine Schritte bringen Dich letztlich auch ans Ziel.

Ein hervorragendes Beispiel für inkrementelles Arbeiten ist eine Internetseite mit einem Blog. Deine gesamte Webseite kannst Du als Product Increment betrachten, dass sich durch einzelne, neue Blogartikel erweitern lässt. Statt also Deine gesamte Webseite im stillen Kämmerlein fertigzustellen und dann – wenn sie fertig ist – online zu stellen, kannst Du mit einem kleinen Webseiten-Kern beginnen und dienen nach und nach mit Hilfe neuer Artikel wertvoller für Deine Leser machen. Mit jedem Blogartikel fügt Deine Internetseite (ein klein wenig) neuen Wert für Deine Leser hinzu.

Gleichzeitig kannst Du mit Hilfe von Analysetools wie Google Analytics, Matomo oder anderen Tools viele Erkenntnisse gewinnen:

Diese Erkenntnisse kannst Du auf verschiedene Weise nutzen. Erstens kannst Du beispielsweise Deinen Redaktionsplan anpassen und mehr Artikel zu Themen schreiben, von denen Du nun weißt, dass sie Deine Webseitenbesucher höchstwahrscheinlich interessieren. Zweitens kannst Du Artikel, die nicht gut funktionieren, noch einmal überarbeiten, um sie wertvoller zu machen. (Denn im Gegensatz zu Kapiteln in einem Buch kannst Du einzelne Blogartikel leicht erneuern und aktualisieren.)

Um sicherzustellen, dass ein Increment wirklich fertig ist, verknüpft der Scrum Guide das Scrum Artefakt mit einem Scrum Commitment: der Definition of Done.

Im Scrum Guide heißt es dazu:

In dem Moment, in dem ein Product Backlog Item die Definition of Done erfüllt, wird ein Increment geboren.

Die Definition of Done (kurz: DoD) hilft Deinem Scrum Team dabei, ein gemeinsames Verständnis von fertig zu etablieren und ist eine Vereinbarung innerhalb Deines Teams, mit dem eine hohe Qualität sichergestellt wird.

Zu Beginn der Entwicklung ist Dein Produkt natürlich noch nicht vollwertig, was den Umfang an Funktionalität angeht. Gleichzeitig sind jedoch die wenigen Funktionen, die bereits vorhanden sind, nutzbar und fertig. Vielleicht lässt sich diese beiden Aapekte auf folgende Formel bringen:

Ein frühes Increment kann nicht alles, was Dein Produkt einmal können soll. Aber das, was es kann, kann es gut.

Ein Walking Skeleton ist ein nutzbares Increment, das lediglich die absoluten Minimal-Anforderungen eines Produktes erfüllt. Die Metapher soll verdeutlichen, dass dem Skelett noch “das Fleisch an den Knoch fehlt”, aber trotz allem lauffähig ist. Ein Walking Skeleton wird jedoch nicht im Live-Betrieb genutzt, da die Kluft zwischen vorhandenem Funktionsumfang und Anforderungen noch viel zu groß ist.

Ein Minimum Viable Product hingegen entsteht dann, wenn der Funktionsumfang eines Increments für den Live-Betrieb ausreicht. Auch ein MVP bietet natürlich noch nicht alles, was sich Kunden und Nutzer vielleicht wünschen.

Das Denken in Increments und ihrer regelmäßigen Auslieferung bringt einige wichtige Konsequenzen mit sich, was die Vorgehensweise bei der Arbeit anbelangt. Die wichtigsten Folgen sind dabei erstens der Fokus auf die Jobs to Be Done der Nutzer, zweitens die Art und Weise, wie User Stories geschnitten werden (müssen) und drittens die häufige Überarbeitung von bereits Existierendem.

Der erste wichtige Aspekt, um Auslieferungen in Form eines Increments zu ermöglichen, ist der Fokus auf den Jobs to Be Done ((JTBD) Deiner Nutzer und Kunden. Es geht also nicht mehr darum, alles in einzelne Produkt-Komponenten zu zergliedern und alle einzelnen Komponenten nacheinander zu bearbeiten, sondern den JTBD, der ermöglicht werden soll, als Grundlage zu nutzen, um alle Komponenten gleichzeitig zu überarbeiten, die notwendig sind, um den Job to Be Done zu ermöglichen.

In der Softwareentwicklung spricht man daher häufig von vertikalem User Story Slicing oder Splitting.

Das bedeutet, dass Features oder User Stories so gesplittet werden, dass der JTBD Deiner Nutzer ermöglicht wird und gleichzeitig alle notwendigen (Software-)Komponenten verändert und überarbeitet werden.

Die regelmäßige Fertigstellung eines Increments bringt es zwangsläufig mit sich, dass Vorhandenes immer wieder überarbeitet werden muss. Das liegt natürlich an der Art und Weise, wie User Stories und andere Product Backlog Items geschnitten werden. Genau hier liegt häufig das Problem für ein Scrum Team (und auch in der Denkweise des Managements).

Denn häufig ist zu beobachten, dass ein Scrum Team der Ansicht ist: “Wenn wir diese Komponente schon anpacken, dann machen wir gleich alles richtig und legen den Grundstein für alles, was noch kommt. Sonst machen wir uns ja selbst doppelte Arbeit!”

Das Resultat sind dann umfangreiche Änderungsmaßnahmen am Produkt, um alles noch (eventuell) Kommende zu bedenken. Deshalb ist es wichtig, genau diese Denkweise innerhalb Deines Teams anzusprechen und allen klar zu machen, dass sie für inkrementelles Arbeiten problematisch oder zumindest hinderlich ist.

Ich hoffe, ich konnte Dir mit diesem Beitrag dabei helfen, das Konzept des Increments in Scrum besser nachzuvollziehen. Falls Du noch Fragen, Ideen, Ergänzungen oder Kritik zu diesem Artikel hast, freue ich mich wie immer über einen Kommentar von Dir hier unten auf der Seite.