.st0{fill:#FFFFFF;}

Scrum Guide

Produktinkrement und die Wichtigkeit für den Sprint

 Oktober 23, 2016

von  Sebastian

Scrum beschreibt das Produktinkrement. Ziel eines Sprints in Scrum ist es immer, ein Produktinkrement zu erstellen und damit einen transparenten Projektfortschritt zu zeigen. Es besitzt damit eine große Wichtigkeit, denn Produktinkrement hat eine ganz zentrale Bedeutung in der Synchronisation und dem gemeinsamen Verständnis im Projekt! Das Inkrement wird im Sprint Review begutachtet. Der Fokus liegt auf dem Erlebbaren und der Maximierung des Feedbacks von Stakeholdern, Meinungen und der wichtigen Diskussion.

Die Eigenschaften vom Produktinkrement

Das Produktinkrement

Wichtige Eigenschaften eine Produktinkrements in Scrum sind:

Inkrementell

Ein Produktinkrement wird inkrementell entwickelt und baut damit 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: er kann das Inkrement erleben und ausprobieren.

Fortschritt

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

Transparenz, Inspektion und Adaption

Durch die Eigenschaft, dass Produktinkremente erlebbar sind, förderst du 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 du das Produktinkrement nicht testest, dann beraubst du dich 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 baust du dir sogenannte Schulden auf. Du erkaufst dir aktuell ein scheinbares fertiges Inkrement, musst in den folgenden Sprints aber Nacharbeiten leisten (Deine Velocity wird sinken).

Nichts zu zeigen

Wenn du mehrere Sprints nichts zu zeigen hast, dann ist es höchste Eisenbahn sich deinen Prozess anzusehen und das Inkrement zu inspizieren:

Denke immer dran, dass Scrum nur funktioniert, wenn du auch die wichtigen Aspekte betrachtest. 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 bist du auch?

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

Achte unbedingt darauf, dass du - egal auf welcher Betrachtungsebene du unterwegs bist - 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 uns 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 du 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 zeigst du Sprint für Sprint, wie du inkrementell wachsenden Wert für eine Zielgruppe aufbauen kannst. 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 deinem konkreten Fall Software sein. Muss es aber nicht, je nachdem was du konkret entwickelst.

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 hast du natürlich einen agilen Grundgedanken zerstört und das Konzept von einem Produktinkrement und User Stories nicht umgesetzt.

Fragen für dein 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 dir gerne ein paar Fragen zur Verfügung, gegen die du reflektieren kannst.

  • Warum machst du Scrum? Welche Vorteile hast du dir davon versprochen?
  • Hast du die Scrum Werte und agile Prinzipien verinnerlicht und verstanden?
  • Benötigst du eine frühe und regelmäßige Lieferung an Ihren Kunden?

Deine eigene Lösung zum Inkrement

Change mit Scrum - der Weg

Auch wenn meine Aussage keine konkrete Lösung auf dein Szenario geben kann, ist es mir wichtig, auf typische Ansätze einzugehen. Reflektiere diese einmal in aller Ruhe.

  • Als eine sehr wichtige Eigenschaft des Inkrements gilt es, dieses erlebbar zu machen. Überlege einmal im Team, in einer Retrospektive, wie du das schaffen kannst. Dazu solltest du unbedingt auch deine Definition of Done zu Rate ziehen.
  • Nutze 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.
  • Nimm die 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 du das Sprint Review nur zum Soll/Ist Vergleich nutzt, dann solltest du dich fragen, ob du wirklich ein Inkrement aktuell erzeust.

Sebastian

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

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

    • 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

  • 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

    • 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

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

    __CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"62516":{"name":"Main Accent","parent":-1}},"gradients":[]},"palettes":[{"name":"Default Palette","value":{"colors":{"62516":{"val":"var(--tcb-skin-color-0)"}},"gradients":[]}}]}__CONFIG_colors_palette__
    Hier gehts lang!
    >

    Psssst - hier gibts was sehr cooles!

    Der Scrum Newsletter

    Willst du mal schauen? :-)