5 2 Votes
Artikel-Rating

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.

Definition eines Increments

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:

Ein Increment ist ein nutzbares und fertiges Produkt. Wird es durch neue Increments erweitert (die ebenfalls fertig & nutzbar sind), entsteht daraus ein neues Increment.
0
Was hältst Du von dieser Definition? Kennst Du noch eine andere, hilfreichere Definition für ein Increment?x
Du kannst Dir ein Increment vorstellen wie einen Würfel, der seinerseits wieder aus vielen kleineren Würfeln besteht.

Das Increment in Scrum

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

Sinn & Zweck des Increments

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.

Transparenz & Risikominimierung

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:

  • Arbeitet die neue Funktion, die wir entwickelt haben, wirklich wie gewünscht?

  • Gibt es irgendwelche Bugs oder andere Fehlfunktionen beim Live-Einsatz?

  • Haben wir alle Anforderungen und Bedarfe unserer Nutzer bedacht?

  • Hat die neue Funktion wirklich die Zeit minimiert, die ein Nutzer braucht, um eine bestimmte Aufgabe zu erledigen?

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).

Kontinuierliche Lieferung von Wert & Nutzen

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.

Beispiel für ein Increment: Internetseite mit Blog

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:

  • Welche Beträge werden häufig gelesen?

  • Wie lange halten sich Besucher auf Deiner Webseite auf und welche Artikel besuchen sie besonders lange?

  • Welche Beiträge erzeugen Interaktion in Form von Kommentaren?

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.)

Auch die Wikipedia kannst Du übrigens als Increment betrachten. Denn jeder neue Artikel in der Online-Enzyklopädie macht sie ein klein wenig wertvoller und nutzbarer.
0
Hast Du noch andere eingängige Beispiele für inkrementelles Arbeiten, die ich hier ergänzen sollte?x

Die Rolle der Definition of Done für das Increment

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.

  • Mehr Details, Informationen und Beispiele dazu findest Du in meinem ausführlichen Artikel zur Definition of Done.

Evolutionsstufen des Increments

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.

Für Increments in einem sehr frühen Entwicklungsstadium haben sich daher zwei Begriffe etabliert, die diesen Gedanken genauer fassbar machen sollen: Walking Skeleton und Minimum Viable Product (MVP).
0
Kennst Du noch andere Begriffe, die ich hier noch ergänzen sollte? Oder verwendest Du die Begriffe hier anders?x

Walking Skeleton

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.

Minimum Viable Product (MVP)

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.

  • Ein hilfreicher Ansatz, um einen Walking Skeleton und den Umfang eines MVP für Dein Produkt zu definieren, ist das sogenannte User Story Mapping, mit dessen Hilfe sich Dein Product Backlog anschließend nach der MoSCoW-Methode priorisieren lässt

Konsequenzen inkrementellen Arbeitens

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.

Fokus auf die Jobs to Be Done der Nutzer

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.

User Story Slicing

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.

  • Eine gute Beschreibung über die genaue Vorgehensweise beim vertikalen Schneiden von User Stories findest Du im Blog von Humanizingwork.

User Story Splitting - Vertikales vs Horizontales Slicing

Häufiges Überarbeiten

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.

Fazit zum Increment

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.