Das Inkrement

Produktinkrement und die Wichtigkeit für den Sprint

Scrum beschreibt das Produktinkrement. Ziel eines Sprints in Scrum ist es immer, ein Produktinkrement zu erstellen und damit den Projektfortschritt zu zeigen. Das Produktinkrement hat eine ganz zentrale Bedeutung in der Synchronisation und dem gemeinsamen Verständnis im Projekt! In diesem Artikel beleuchte ich dieses am Ende des Sprints entstehende Produktinkrement genauer und beschreibe, was oft falsch gemacht wird.

Das Inkrement wird im Sprint Review begutachtet. Der Fokus liegt auf dem Erlebbaren und Gewinnung von Feedback, Meinungen und der wichtigen Diskussion mit den Stakeholdern.

In diesem Artikel möchte ich für Sie Inhalt, Theorie und Praxis beleuchten. Und wenn Sie Probleme haben, das Inkrement zu definieren, finden Sie am Ende dazu weitere Hinweise.

Die Eigenschaften vom Produktinkrement

Das Produktinkrement

Werfen wir nun gemeinsam einen Blick auf wichtige Eigenschaften des Produktinkrements.

Inkrementell

Ein Produktinkrement wird inkrementell entwickelt und baut aufeinander auf!

Erlebbar

Das Produktinkrement kann durch die Zielgruppe inspiziert werden.

Mehrwert

Ein Inkrement erzeugt immer einen Mehrwert und ist nie Selbstzweck.

Getestet

Ein Produktinkrement wird innerhalb des Sprint immer getestet.

Kunde

Es geht um den Kunden: das Inkrement kann durch ihn interpretiert werden.

Fortschritt

Am Inkrement kann der Fortschritt über das Produkt betrachtet werden.

Transparenz, Inspektion und Adaption

Durch die Eigenschaft, dass Produktinkremente erlebbar sind, fördern sie einen Produkt-Meilenstein, der verlässlich ist. Nur das, was wirklich funktioniert und erlebbar ist, kann bewertet werden. Genau dieser Zustand zeigt den Projektfortschritt und steht im Fokus am Ende des Sprints. Scrum basiert sehr stark auf dieser Art der Transparenz und dem dann folgenden Inspect & Adapt.

Häufige Fehler beim Inkrement

Keine Tests

Wenn Sie das Produktinkrement nicht testen berauben Sie sich mehrerer fantastischen Möglichkeit bei der Entwicklung: 

  • Die Gewissheit, ob das Inkrement funktioniert.
  • Den tatsächlichen Projektfortschritt.
  • Das Verständnis des Kunden.

Ohne Tests mit dem Inkrement bauen Sie sogenannte Schulden auf. Sie erkaufen sich aktuell ein scheinbares fertiges Inkrement, müssen in den folgenden Sprints aber Nacharbeiten leisten (Velocity wird sinken) müssen und gelangen so in eine Abwärtsspirale.

Nichts zu zeigen

Wenn Sie mehrere Sprints nichts zu zeigen haben, dann ist es höchste Eisenbahn sich Ihren Prozess anzusehen und das Inkrement zu inspizieren:

Denken Sie immer dran, dass Scrum nur funktioniert, wenn Sie auch die wichtigen Aspekte betrachten. Laufend kein Produktinkement zeigen zu können, lässt auf schwere Probleme schließen.

Skalierung

Ein Team entwickelt ein Produkt und zeigt am Ende des Sprints immer ein Produktinkement. Soweit sind Sie auch?

  • Reine Teambetrachtung führt bei einer Skalierung zu keinem Erfolg.
  • Der Wertstrom muss beachtet werden.
  • Teams müssen gemeinsam etwas zeigen!

Achten Sie auch hier unbedingt immer darauf, dass Sie - egal auf welcher Betrachtungsebene unterwegs sind - dass ein Inkrement vorhanden ist.

Verständnis des Produktinkrements

Durch den Kommentar eines meiner Leser, möchte ich diesen Abschnitt explizit noch einmal dafür nutzen, das Verständnis über das Produktinkrement zu verdeutlichen. Dabei ist es mir wirklich wichtig, dass wir über dasselbe sprechen, denn sonst gehen sowohl die Erwartungshaltung als auch agile Grundgedanken verloren.

Das Produktinkrement im Scrum Guide

Schauen wir gemeinsam einmal in den Scrum Guide und sehen und die Passage zum Inkrement genauer an. Ich zitiere diesen in der englischen Originalfassung:

Scrum Guide

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

Das bedeutet nun konkret, dass Sie immer eine gewisse Anzahl von Product Backlog Items aus Ihrem Backlog umsetzen. Dabei beachten Sie bitte immer Ihre Definition of Done. Es geht letztendlich nur darum, dass das Inkrement eine inspizierbare Arbeit ist, die Empirie unterstützt. Damit das nicht planlos angegangen wird, gibt es immer die Vision als übergreifendes Ziel und dazu Sprint Ziele.

Ein Inkrement ist keine Software sondern Wert

Auch wenn diese Annahme nicht mehr so verbreitet ist wie früher, ist es mir noch einmal wichtig darauf hinzuweisen, dass ein Inkrement keine Software sein muss.

Mit einem Inkrement zeigen Sie Sprint für Sprint, wie Sie inkrementell wachsenden Wert für eine Zielgruppe aufbauen können. Dieser Wert muss dabei erlebbar sein, dass bedeutet wiederum, dass sich das Inkrement Stakeholder, Product Owner und Endkunden anschauen können. Sie können damit interagieren.

Natürlich kann dieses Produktinkrement in Ihrem konkreten Fall dann Software sein. Muss es aber nicht, je nachdem was Sie konkret entwickeln.

Hilfe, ich habe kein Produktinkrement

Gerade größere Unternehmen haben zu Beginn noch keine richtige Vorstellung von Ihrem Inkrement. Was sich in der Praxis dann vorfindet ist sehr häufig der folgende Fall:

  • Es findet eine Sprint Planung statt und dort gibt es häufig schon User Stories (diese werden fast immer so genannt, obwohl das Konzept dahinter oft nicht verstanden ist) die im Sprint verteilt werden.
  • Die User Stories erzeugen oft keinen echten Wert und sind auch nicht unabhängig. Demnach ist es schwer, diese Stories im Sprint durch den Product Owner abzunehmen.
  • Am Ende des Sprints werden die Stories durchgegangen, abgenommen oder nicht. Alles was nicht geschafft wurde, liegt wieder (und das ist sehr auffällig!) oben auf dem Backlog. Denn: die Abfolge muss eingehalten werden, da sonst etwas nicht umgesetzt werden kann (Typische Abhängigkeiten).

Damit haben Sie natürlich einen agilen Grundgedanken zerstört und das Konzept von einem Produktinkrement und User Stories nicht umgesetzt.

Fragen für Ihr Inkrement

Ich bin kein Freund, obiges Szenario mit klaren Fakten zu beantworten. Denn die Situationen und die Gründe in den Unternehmen sind dazu viel zu vielfältig. Aber ich stelle gerne ein paar Fragen zur Verfügung, gegen die Sie reflektieren können.

  • Warum machen Sie Scrum? Welche Vorteile haben Sie sich davon versprochen?
  • Haben Sie Scrum Werte und agile Prinzipien verinnerlicht und verstanden?
  • Benötigen Sie eine frühe und regelmäßige Lieferung an Ihren Kunden?

Ihre eigene Lösung zum Inkrement

Change mit Scrum - der Weg

Auch wenn ich meine Aussage keine konkrete Lösung zu geben hier wieder etwas aufweiche, ist es mir wichtig, auf typische Ansätze einzugehen. Reflektieren Sie diese einfach einmal in aller Ruhe.

  • Als eine sehr wichtige Eigenschaft des Inkrements gilt es, dieses erlebbar zu machen. Überlegen Sie also einmal im Team, in einer Retrospektive, wie Sie das schaffen können. Dazu sollten Sie unbedingt auch Ihre Definition of Done zu Rate ziehen.
  • Nutzen Sie User Stories, wie sie gedacht sind. Eine User Story muss dabei in einen Sprint passen, nicht abhängig zu anderen sein und einen Wert liefern. Auch wenn das vielleicht nicht immer klappt, Ziel sollte es sein.
  • Nehmen Sie User Stories schon während des Sprints ab. Das hilft um einen frühen Indikator zu bekommen, wie es um das Inkrement steht.

Hinweis

Immer wenn Sie das Sprint Review nur zum Soll/Ist Vergleich nutzen können, dann sollten Sie sich fragen, ob Sie wirklich ein Inkrement aktuell erzeugen.

Leave a Reply 4 comments

Rolf Rademaker Reply

Ist ein Produktinkrement z. B. auch ein Berechtigungskonzept für eine Plattform?
Man sieht es hinterher nicht wirklich und zeigen kann man max. die Dokumentation dazu.

    Sebastian Schneider Reply

    Hallo und vielen Dank für den Kommentar!

    Dazu folgende Überlegungen / Gedankengänge:

    – Ein Inkrement erzeugt inkrementellen Wert für Kunden / Zielgruppe von Iteration zu Iteration
    – Ein Berechtigungskonzept erscheint mir mehr ein Feature, als ein Inkrement. Ich würde mir die Frage stellen, wie ich inkrementell dieses Feature umsetzen und auch zeigen kann. Mal ganz frei gesprochen, könnte das in einem frühen Sprint tatsächlich etwas sein, was sich noch gar nicht als Code zeigt. sondern eine Möglichkeit zur Reflexion bietet. Dann wächst es über immer neue Rollen und Berechtigungen.
    – Auch wenn man etwas “nicht sieht”, gibt es nicht Szenarien, die ich “nachstellen” kann?
    – Muss ein Berechtigungskonzept immer gleich alle Rollen umfassen? Wäre es denkbar mit wichtigen Rollen und wichtigen Aufgaben zu beginnen?
    – Wenn ich nichts zeigen kann, kann ich etwas simulieren? Automatisieren?
    – Das Problem bei allem, was man “nicht zeigen” kann ist immer, man benötigt Aufwand extra etwas zu erstellen, um es eben irgendwie zu zeigen. Das ist in der Regel nicht im Sinne des Erfinders und erzeugt nur “waste”

    Zudem würde ich mir ansehen, wo das Team steht. Warum sieht das Inkrement so aus wie es aussieht? Wissen sie es nicht besser? Geht es nicht besser? Warum haben Sie das Inkrement so gewählt?

    Das ist ein guter Impuls, ich werde dazu noch etwas im Artikel verarbeiten 🙂

    Viele Grüße
    Sebastian Schneider

Marc Thürkauf Reply

Guten Tag

Wir arbeiten in der IT-Infrastruktur und stellen physische wie virtuelle Server zur Verfügung, setzen Konfigurationen um. Leider ist es für uns in der Basis sehr schwierig die umgesetzten Stories am Review sichtbar zu machen.
Wir haben nichts entwickelt, können keine E2E Prozess aufzeigen, sondern legen immer nur das Fundament für die Entwickler…
Haben Sie dazu ein paar Ideen?
Meine war, dass man das Team so mischt, dass auch Entwickler im Team sind, doch das sei organisatorisch nicht möglich.
Danke und Gruss
Marc

    Sebastian Schneider Reply

    Hallo Marc,

    danke für den interessanten Einblick. Dazu hätte ich ein paar Fragen:
    – ihr stellt zum einen Hardware, zum anderen virtuelle – also SW basierte – Server mit Scrum her, ist das so richtig?
    – Wie sieht denn eine solche typische User Story aus?
    – Wie führt ihr das Review durch? (Format, was wird gezeigt, Methoden?)

    Beste Grüße
    Sebastian

Leave a Reply:







>
close

Der neue Online Scrum Kurs!

Der Online Scrum Kurs