Scrum im Selbststudium – Teil 9: Die Vergangenheit – Das Produkt-Inkrement
Willkommen zum 9. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.
Im letzten Teil haben wir das Sprint Backlog mit seinen drei Bestandteilen betrachtet. In diesem Teil schauen wir auf das, was schon geschaffen wurde: Das Produkt-Inkrement.
Der Zweck jedes Inkrements ist, Annahmen über die bisher geleistete Arbeit zu validieren. Es macht somit die vergangene Arbeit transparent.
Das Inkrement ist das primäre Mittel, mit dem Scrum-Teams empirische Prozesskontrolle für komplexe Probleme ausüben. Menschen, die ein Interesse an dem Produkt haben, können es inspizieren und feststellen, ob es ihren Bedürfnissen entspricht, wenn sie verstehen, wie es funktioniert und ob es ihre Erwartungen erfüllt. Ferner ist es das wichtigste Maß für den Fortschritt eines Scrum-Teams:
„Ein Increment ist ein konkreter Schritt in Richtung des Produkt‐Ziels.“ – Scrum Guide, 2020
Während eines Sprints kann ein Inkrement erstellt werden, wenn ein Product-Backlog-Eintrag aus dem Sprint Backlog fertig ist.
„In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren.“ – Scrum Guide, 2020
Um Verwirrung und unterschiedliche Erwartungen zu vermeiden, gilt ein Product-Backlog-Eintrag erst dann als „fertig“, wenn er gründlich überprüft wurde und der Definition of Done entspricht, zu der sich das Scrum-Team verpflichtet hat.
Definition of Done: Die Verpflichtung gegenüber der Qualität
Der Zweck, der Scrum in einem einzigen Satz zusammenfasst, lautet:
Empirisches Arbeiten ermöglichen, indem mindestens einmal pro Sprint ein fertiges Inkrement erstellt wird.
Deshalb ist es auch so wichtig, dass Scrum-Teams Zeit darauf verwenden, zu klären, was „fertig“ für ihr Produkt bedeutet. Welche Arbeit ist dafür erforderlich? Welche Prüfungen und Tests sind notwendig, um den internen Qualitätsrichtlinien des Teams zu entsprechen? Wer muss daran beteiligt sein?
Das gemeinsame Verständnis, was es bedeutet, wenn ein Eintrag des Product Backlogs fertig ist, wird als Definition von Done bezeichnet.
„Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“ – Scrum Guide, 2020
Somit macht die Definition of Done das Inkrement transparent.
Sie stellt sicher, dass das Scrum-Team und die Stakeholder das Gleiche darunter verstehen, wann Arbeit als fertig bezeichnet wird. Die Definition of Done hält fest, welche Arbeiten abgeschlossen werden müssen, damit die erforderliche Qualität für das Produkt erfüllt ist.
Häufig wird die Definition of Done als eine Checkliste festgehalten. Im Falle eines typischen Softwareprodukts könnte die Liste Folgendes umfassen:
- Code ausreichend refaktorisiert und dokumentiert
- Code Reviews durchgeführt
- alle Lokalisierungen erstellt
- Integrationstests bestanden
- Performancetests bestanden
- Stabilitätstests bestanden
- Regressionstests bestanden
- Release Notes geschrieben
- Akzeptanztest bestanden
- Benutzerdokumentation erstellt
- bereit, auf die Produktivumgebung ausgeliefert zu werden
Eine wichtige Qualitätsfrage, welche die Definition of Done festhält, ist: Was bedeutet es, dass das Inkrement nutzbar ist?
„Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.“ – Scrum Guide, 2020
Denn nur die Nutzbarkeit reduziert das Risiko in der Entwicklung von Produkten. Wenn du dir einen typischen Softwareentwicklungsprozess anschaust, dann enthält er etwa die folgenden Stufen:
- Code programmiert
- Software getestet
- neue Software in das bestehende Produkt integriert
- Software bereit zum Release
- Software wird von Nutzern verwendet
Damit Scrum-Teams einen Eintrag des Product Backlogs als „done“ bezeichnen dürfen, muss er bereit zum Release sein. Die neue Software muss vom Endanwender nutzbar sein, wenn sich das Scrum-Team entscheidet, sie dem Nutzer zur Verfügung zu stellen. Mit anderen Worten:
Das Inkrement wird zum Teil des Produkts.
Nur wenn die Software bereit zum Release ist, sind keine weiteren Entwicklungsarbeiten mehr nötig, um das Inkrement auszuliefern. Ist dieser Zustand nicht erreicht, dann gibt es noch ungetane Arbeit. Diese „undone Work“ birgt noch viele Risiken, es kann zu unvorhergesehenen Komplikationen bei der Erstellung, den Tests oder der Integration in das Produkt kommen. Erst wenn ein Product-Backlog-Eintrag die Definition of Done erfüllt, ist dieses Risiko vollständig eliminiert.
Arbeit des Scrum-Teams, die nicht nutzbar ist, stellt kein Inkrement dar
Da ein Inkrement geboren ist, wenn ein Eintrag im Sprint Backlog die Definition of Done erfüllt, können auch mehrere Inkremente in einem Sprint erstellt werden.
Generell sollte jedes Inkrement additiv zu allen vorherigen Inkrementen sein. Das heißt, Inkremente müssen gründlich geprüft sein, um sicherzustellen, dass sie alle zusammen funktionieren.
„Die Summe der Incremente wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden. – Scrum Guide, 2020
Wenn ein Product‐Backlog‐Eintrag nicht der Definition of Done entspricht, ist er weder Teil des Inkrements, noch darf er den Nutzern freigegeben werden und sollte auch nicht im Sprint Review vorgestellt werden. Stattdessen wandert er zur zukünftigen Berücksichtigung in das Product Backlog zurück. Der Product Owner kann dann entscheiden, wie damit zu verfahren ist. Dies untermauert die Tatsache, dass Scrum-Teams niemals die Qualität für eine höhere Entwicklungsgeschwindigkeit opfern sollten. Etwa indem sie bei einem Produkt-Backlog-Eintrag auf zeitaufreibende automatisierte Tests verzichten, um die Software schneller dem Kunden zu Verfügungen stellen können. Sollte dies doch vorkommen, bezeichnen wir dies als „technische Schulden“. Diese „Schulden“ sollten umgehend zurückgezahlt werden, sonst bremsen die „Tilgungszahlungen“ das Scrum-Team nachhaltig aus.
Wer erstellt die Definition of Done?
Wenn die Definition of Done Teil der Standards der Organisation ist, muss jeder, der eine Änderung am Produkt vornimmt, diese als Mindestmaß befolgen. Das gilt auch für das Scrum Team. Allerdings steht dem Team frei, noch ergänzende Elemente zur Definition of Done, die nicht Teil der Standards der Organisation sind, hinzuzufügen. Wenn die Definition of Done kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.
Ausblick: Im nächsten Teil geht es um die Überprüfung der drei Artefakte, die wir in den letzten drei Teilen behandelt haben. Dafür zuständig: Die Scrum Events.
Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.
Hier findest du alle Teile der Reihe “Scrum im Selbststudium”:
Teil 1: Agile Projekte sind erfolgreicher
Teil 2: Scrum in 11 Schritten im Schnelldurchlauf erklärt
Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt
Teil 5: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen
Teil 6: Die Scrum Artefakte stellen Transparenz her
Teil 7: Die mögliche Zukunft – Das Product-Backlog
Teil 8: Die Gegenwart – Das Sprint Backlog
Teil 9: Die Vergangenheit – Das Produkt-Inkrement
Teil 10: Scrum Events erlauben, die Artefakte zu überprüfen und anzupassen
Teil 11: Sprint – Erstellung eines Inkrements
Teil 12: Sprint Planning – Planung der Arbeit des Sprints
Teil 14: Sprint Review – Überprüfung der Sprint-Ergebnisse und weitere Planung
Teil 15: Sprint Retrospektive – Aus dem vergangenen Sprint lernen und Verbesserungen planen
Teil 16: Das Scrum-Team und seine Verantwortung
Teil 17: Der Product Owner maximiert den Wert des Produkts
Teil 18: Die Entwickler schaffen jeden Sprint ein nutzbares Inkrement
Teil 19: Der Scrum Master verantwortet die Effektivität des Scrum-Teams