Was ist ein Inkrement?

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

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

Jedes Inkrement ist additiv zu allen vorherigen Inkrementen und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Inkrement 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 Inkrement versuchen:

Ein Inkrement ist ein nutzbares und fertiges Produkt. Wird es durch neue Inkremente erweitert (die ebenfalls fertig & nutzbar sind), entsteht daraus ein neues Inkrement.

Du kannst Dir ein Inkrement vorstellen wie einen Würfel, der seinerseits wieder aus vielen weiteren, kleineren Würfeln besteht.

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 Inkrement legt. Nun, dafür gibt es zwei wichtige Gründe. Erstens entsteht nur durch ein Inkrement ausreichend Transparenz. Und zweitens erzeugt ein Inkrement 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 größten, wenn ein 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 Inkrement 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 Inkrement 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 Inkremente 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 Produkt-Inkrement betrachten, das sich durch einzelne, neue Blogartikel erweitern lässt. Statt also Deine gesamte Webseite im stillen Kämmerlein fertigzustellen und erst dann – wenn sie komplett fertig ist – online zu stellen, kannst Du mit einem kleinen Webseiten-Kern beginnen und diesen nach und nach mit Hilfe neuer Artikel wertvoller für Deine Leser machen. Mit jedem neuen Blogartikel fügst Du Deiner 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 Inkrement 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 Inkrement 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. Trotzdem sind die wenigen Funktionen, die bereits vorhanden sind, nutzbar und fertig. Oder auf eine einfache Formel gebracht:

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

Ein Walking Skeleton ist ein nutzbares Inkrement, 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 Inkrements 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 Inkrementen 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 Inkrements zu ermöglichen, ist der Fokus auf den Jobs to Be Done (JTBD) Deiner Nutzer und Kunden. Es geht nicht mehr ausschließlich darum, alles in einzelne Produkt-Komponenten zu zergliedern und die 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 Inkrements 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 Inkrements 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.