Unser Unternehmen führt einige Scrum-Experimente durch, und ich habe eine kurze Frage dazu, woraus genau ein Sprint bestehen sollte.
Nach dem Sprint-Planungsmeeting haben wir uns auf drei verschiedene Geschichten geeinigt. Eine Story steht komplett für sich und kann am Ende des Sprints fertiggestellt und gestartet werden. Die anderen beiden sind jedoch kleinere Teile eines größeren Merkmals.
Ist es üblich, das konzeptionelle Thema eines Sprints so aufzuteilen, oder sollten sich alle Geschichten auf das große Feature konzentrieren?
Idealerweise sollte ein Sprint eine kohärente Erhöhung der Funktionalität bieten. In der Praxis können Teams Geschichten einbringen, die nicht auf das einzelne Sprint-Ziel ausgerichtet sind, aber dies erfordert fortgeschrittenes Scrum-Fu. Selbst wenn zusätzliche Geschichten hinzugezogen werden, sind einige Strategien erfolgreicher als andere, und es muss sorgfältig darauf geachtet werden, dabei nicht gegen die grundlegenden Scrum-Prinzipien zu verstoßen.
Eine der am häufigsten übersehenen Anforderungen des Scrum-Frameworks ist die Notwendigkeit eines Sprint-Ziels, das jede Iteration leitet. Die kanonische Definition des Sprint-Ziels wird hier beschrieben:
Das Sprint-Ziel ist eine Zielsetzung für den Sprint, die durch die Implementierung des Product Backlog erreicht werden kann. Es bietet dem Entwicklungsteam eine Anleitung, warum es das Inkrement erstellt. Es wird während des Sprint-Planning-Meetings erstellt. Das Sprint-Ziel gibt dem Entwicklungsteam eine gewisse Flexibilität hinsichtlich der im Sprint implementierten Funktionalität. Die ausgewählten Product-Backlog-Elemente liefern eine kohärente Funktion, die das Sprint-Ziel sein kann. Das Sprint-Ziel kann jede andere Kohärenz sein, die dazu führt, dass das Entwicklungsteam eher zusammenarbeitet als an getrennten Initiativen.
— The Scrum Guide , Schwaber und Sutherland, S.10
Der Text muss ein wenig analysiert werden, aber das Kernkonzept ist, dass ein Sprint-Ziel die Grundlage der Iteration ist. Ein Sprint scheitert oder gelingt nicht basierend darauf, wie viele Storys am Ende des Sprints fertig oder nicht fertig sind; Erfolg entsteht nur durch das Erreichen des durch das Sprint-Ziel definierten Ziels.
Wenn Ihr Sprint-Ziel „einen Haufen Geschichten erzählen“ oder „dieses, jenes und noch etwas vervollständigen“ lautet, dann verlieren Sie die eigentliche Essenz von Agilität. Das Team ist nicht in der Lage, mit dem Product Owner und den Stakeholdern zusammenzuarbeiten, um einen optimalen Weg zum Erreichen des erklärten Ziels zu finden; Stattdessen ist das Team gezwungen, nur durch die 100-prozentige Erfüllung der vorgeschriebenen Work-Breakdown-Pakete erfolgreich zu sein.
Jeder Sprint sollte ein einzelnes Sprint-Ziel haben, und der Erfolg des Sprints hängt davon ab, ob das Sprint-Ziel am Ende der Iteration erreicht wurde. Da es sich bei einem Sprint jedoch um eine Zeitbox mit fester Länge handelt, stehen dem Team manchmal zusätzliche Kapazitäten zur Verfügung, nachdem das Sprintziel erreicht wurde. Dies führt zu mehreren Optionen.
Die erste Möglichkeit besteht darin, dass der Product Owner eine vorzeitige Beendigung des Sprints fordert. Wenn Sie einen einmonatigen Sprint haben, aber Ihr Sprintziel in einer Woche erreichen, ist dies sicherlich eine vernünftige Vorgehensweise. Vorzeitige Beendigungen sind jedoch mit einem Prozessaufwand verbunden. Wenn Sie also häufig in diese Situation geraten, sollten Sie Ihre Sprintlänge reduzieren und sich vorzeitige Beendigungen für wirklich ungewöhnliche Umstände aufsparen.
Die zweite Option besteht darin, sicherzustellen, dass sich das Team nur auf Storys im Zusammenhang mit dem aktuellen Sprint-Ziel festlegt, aber jede zusätzliche Kapazität, die nach Erreichen des Sprint -Ziels verbleibt, nutzt , um zusätzliche Storys aus dem Product Backlog zu entfernen. Dies geschieht natürlich in Zusammenarbeit mit dem Product Owner, der mit dem Team zusammenarbeitet, um User Stories zu identifizieren, die:
Die Strategie zum Füllen von Überkapazitäten ist diejenige, die erfahrene Teams im Allgemeinen am effektivsten finden. Es bewahrt die Integrität des Sprint-Ziels und hält die iterative Kadenz stabil, verleiht dem Prozess aber auch die dringend benötigte Flexibilität. Denken Sie daran, dass es bei Sprints darum geht, ein nachhaltiges Entwicklungstempo im Laufe der Zeit aufrechtzuerhalten, und der Vorrang des Sprint-Ziels ist eine der effektivsten Möglichkeiten, dieses Tempo richtig festzulegen.
Natürlich verfallen einige Teams dem Trugschluss der 100-prozentigen Auslastung und gehen davon aus, dass das Ziel darin besteht, das Team bei jeder Iteration mit voller Kapazität arbeiten zu lassen, unabhängig davon, ob Prozessflaute oder flexible Geschäftsziele erforderlich sind. Solche Teams füllen ihren Sprint normalerweise basierend auf historischen Geschwindigkeitsmustern oder willkürlichen Managementzielen bis zum Rand aus.
Dieser Ansatz ist mit vielen Problemen verbunden, darunter ein reduzierter Fokus auf das Produktinkrement und eine reduzierte Anpassungsfähigkeit an sich ändernde Geschäftsziele. Es macht es für ein Team auch sehr schwierig festzustellen, ob ein bestimmter Sprint erfolgreich war oder nicht. Am Ende eines Sprints, selbst wenn Sie 100 % der Storys abgeschlossen und alle zu 100 % beschäftigt haben, wie können Sie ohne ein zusammenhängendes Ziel wissen, dass Sie das Richtige gebaut haben?
In einigen Bereichen kann diese Rahmenregel erfolgreich gebrochen werden, aber sie verkompliziert den Prozess sicherlich enorm. Wenn Ihr Scrum-Fu so weit fortgeschritten ist, dass Sie diese Regel brechen können, indem Sie Ihre Inspektions- und Anpassungszyklen nutzen, den Erfolg richtig messen und ein nachhaltiges Tempo beibehalten, dann machen Sie weiter.
Es gibt sicherlich Fälle, in denen mehrere Ziele oder eine zielübergreifende Sprintplanung funktionieren können, aber es ist wie das Jonglieren mit Kettensägen. Ich empfehle es nicht – es sei denn, Sie planen natürlich, Ihre todesmutige Jongliernummer zu nutzen, um dem Zirkus beizutreten.
So wie ich es gesehen habe (ich arbeite derzeit in einer großen Firma, die skalierte Agilität durchführt) basiert die Arbeit eines Sprints auf Kapazität und Priorität, nicht unbedingt auf einem Thema. Wir haben häufig Funktionen, die sich in mehrere Geschichten zerlegen, die nicht unbedingt alle innerhalb eines einzigen Sprints erledigt werden – insbesondere, wenn wir Abhängigkeiten von anderen Teams haben (z. B. müssen wir einen Service erstellen/modifizieren).
Daher sehe ich kein Problem mit dem Ansatz, den Sie verfolgen.