Das wichtigste Scrum-Artefakt ist das Produktinkrement. Während des Sprints produziert das Entwicklungsteam ein potenziell releasefähiges Produktinkrement. Diese Produkterweiterung muss sich an der „Definition of Done“ des Entwicklungsteams orientieren und vom Product Owner akzeptiert werden.

Was ist ein Inkrement in Scrum?

Wie im Scrum Guide beschrieben, ist ein Inkrement die Summe aller während eines Sprints abgeschlossenen Produkt Backlog Items und aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement „Done“ sein, d.h. es muss sich in einem brauchbaren Zustand befinden und der Definition des Scrum Teams von „Done“ entsprechen. Jedes Inkrement ist ein Schritt in Richtung einer Vision oder eines Ziels. Die Inkremente müssen sich in einem brauchbaren Zustand befinden, unabhängig davon, ob der Product Owner beschließt, sie freizugeben. Der Sinn von Scrum besteht darin, ein Inkrement zu liefern, dass „Done“ ist. Entwicklungsteams liefern in jedem Sprint ein Inkrement der Produktfunktionalität. Ein Product Owner hat demnach sofort die Möglichkeit, das Inkrement freizugeben. Die Definition of „Done“ gewährleitstet Transparenz über Fortschritt und Qualität. Annahmen gilt es zu überprüfen, um daraus zu lernen.

Herausforderungen bei der Erstellung eines fertigen Inkrements

Fehlende Teamverantwortung

Das Entwicklungsteam ist als Ganzes verantwortlich, um bis zum Ende des Sprints ein fertiges Inkrement zu erstellen. Wenn Teammitglieder sich nicht in dieser Gesamtverantwortung sehen, leidet oft das Gesamtergebnis des Sprints. Teammitglieder kümmern sich dann nur um ihre eigenen Produkt Backlog Items. Ein häufiges Zeichen für mangelnde Teamfähigkeit ist viel WIP (Work in Progress). Produkt-Backlog-Items im Sprint Backlog werden dann oft auf den nächsten Sprint „übertragen“. Einzelne Teammitglieder konzentriert sich in diesem Zuge nicht auf den gesamten Plan oder das gesamte Team. Qualitätsprobleme sind wahrscheinlich weit verbreitet, aber das Team diskutiert sie nicht.

Fehlende Zusammenarbeit

Wenn ein Team die Phasen der Gruppenentwicklung durchläuft [link], verlagert es sich von der Koordination zur Zusammenarbeit. Ohne Zusammenarbeit werden Lösungen durch die Erfahrung und das Wissen des Einzelnen eingeschränkt. Kollaboration ermöglicht, dass die kreativsten und effektivsten Lösungen an die Oberfläche kommen. Dies steht in engem Zusammenhang mit der Eigenverantwortung des Teams. Durch fehlende Zusammenarbeit entsteht eine Menge WIP, welcher durch Teammitglieder verursacht wird, die jeweils an einem anderen Product Backlog Item arbeiten. Mangelnde Zusammenarbeit kann darüber hinaus zu Problemen führen, wenn Teammitglieder versuchen, ihre individuellen Leistungen zu integrieren.

Es gibt kein klares Sprintziel

Ein Sprintziel ist ein messbares Ziel für den Sprint, das dem Team Fokus und Flexibilität bietet. Es besteht die Erwartung, dass alle Product Backlog Elemente im Sprint Backlog abgeschlossen sind. Es entsteht durch Verhandlungen zwischen dem Product Owner und dem Entwicklungsteam. Ohne konkretes Ziel, kann das Entwicklungsteam aus den Augen verlieren, was am wertvollsten ist und welchen Zweck der Aufbau des Inkrements hat. Es kann daher zu Streitigkeiten kommen, woran als nächstes gearbeitet werden soll. Das Sprintziel darf nicht vage formuliert sein. Alle Teammitglieder müssen am Ende eines Sprints mit 100%iger Sicherheit wissen, ob das Sprintziel erreicht wurde oder nicht. Das Sprintziel ist aus vorherigen Zielen zusammengemischt. Dies passiert vor allem bei einem Übertrag der vorigen Backlog Items. Zusammengesetzte Sprintziele bieten möglicherweise nicht genügend Fokus und Flexibilität.

Zu viel Veränderung während des Sprints

Änderungen während eines Sprints sind zwar zu vermeiden, jedoch immer wieder zu erwarten. Dies kann daran liegen nicht alle Teammitglieder alles über die Features und Funktionen wissen, die sie liefern werden. Eine Beauftragung mit zusätzlichen Arbeiten außerhalb des Entwicklungsteams, könnten Mitglieder des Entwicklungsteams stark ablenken. Auch eine Änderung des Sprintziels durch den Product Owner kann Teams bei der Entwicklung stören. Darüber hinaus sollte man immer mit natürlichen Entwicklungen rechen, die zu Änderungen während des Sprints beitragen. So können neu hinzugewonnen Erkenntnisse unterschiedliche Perspektiven auf Backlog Items schaffen. Man muss also die äußeren Einflüsse balancieren und über eine Zulassung nachdenken.

Hindernisse beseitigen

Teams können technische oder prozessuale Hindernisse haben, die sie verlangsamen oder daran hindern, ein Inkrement zu erstellen. Die Beseitigung von Hindernissen trägt zur Verbesserung des Arbeitsablaufs bei und kann langfristig zu einer höheren Qualität und einer einfacheren Bereitstellung von Verbesserungen führen. Es muss daher sichergestellt sein, dass das Team über das Wissen und die Werkzeuge verfügt, die es zur Implementierung der Automatisierung benötigt. Außerdem ist darauf zu achten, ob es jemanden außerhalb des Teams gibt, der bestimmte Aufgaben erfüllen oder Genehmigungen erteilen muss, um eine abgeschlossene Erhöhung zu erstellen?

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick