Scrum besagt, dass sich das Team dazu verpflichten sollte, die Stories im Sprint Backlog zu liefern. Es wird vorausgesetzt, dass nach Erreichen dieses Limits keine weiteren Elemente zum Sprint-Backlog hinzugefügt werden.
Sollte das Sprint-Backlog mit der MoSCoW-Methode offen priorisiert werden ? Damit waren die Erwartungen des Product Owners für X% der Frühjahrs-Backlog-Aufgaben wie folgt:
Soweit ich sehen kann, profitiert dieser Ansatz von:
Dieser Ansatz verkompliziert jedoch das Konzept von Teams, die sich verpflichten, den gesamten Sprint-Backlog zu liefern.
Hat jemand einen Beitrag zu den Vor- und Nachteilen dieses Ansatzes zur Sprintplanung? Oder Erfahrung mit der Implementierung von etwas Ähnlichem?
Nein. Tu das nicht.
Lediglich die Aufgaben im Product Backlog konnten über die MoSCoW-Methode priorisiert werden. Wenn man das tun würde, was Sie vorschlagen, und versuchen würde, eine Verteilung der Prioritäten im Sprint-Backlog zu erhalten, würde das Team diese Projektprioritäten ignorieren.
Stellen Sie sich die Situation vor, in der Ihr Projektbestand 6000 Muss-, 2000 Soll-, 1500 Könnte-Haben- und 500 Nicht-Haben-Möglichkeiten enthält. Dann starten Sie einen Sprint mit einer tatsächlichen Geschwindigkeit von 20 Storys (in diesem hypothetischen Szenario haben alle Storys identische Story-Point-Kosten). Wenn Sie die MoSCoW-Methode für das Sprint-Backlog verwenden würden, würden Sie während dieses Sprints am Ende 12 Must-haves, 4 Must-haves, 3 Could-haves und 1 Want-not-have erreichen.
Vergleicht man das mit der Alternative, einfach 20 Must-Have-Storys in den Sprint zu nehmen, wird meiner Meinung nach deutlich, welcher Ansatz der bessere ist. Unter der Annahme einer konstanten Geschwindigkeit benötigt die MoSCoW-Sprint-Methode 500 Sprints, um alle Must-Haves zu vervollständigen, während sie sich nur auf die Rückstandsprioritäten verlassen würden, um sie alle in 300 Sprints zu vervollständigen (wiederum unter der Annahme dieser hypothetischen Situation, in der jede Geschichte den gleichen Aufwand erfordert und nichts blockiert etwas).
Wenn einem Entwicklungsteam während des Sprints die Arbeit ausgeht, sollte der Product Owner informiert werden und entweder der Sprint vorzeitig beendet oder dem Sprint dann mehr Arbeit hinzugefügt werden. Dies sollte idealerweise nicht sehr häufig vorkommen. Wenn ein Entwicklungsteam die Arbeit für seine Sprints ständig unterschätzt, dann gibt es Probleme mit seinem Schätzungsprozess.
Funktionen/Fähigkeiten/Leistungen/Aufgaben sollten (im Produkt-Backlog) mithilfe von MoSCoW während der Anforderungserfassung vor Beginn Ihres ersten Sprints und nach Bedarf während nachfolgender Meetings zur Verfeinerung des Produkt-Backlogs priorisiert worden sein. Während solcher Verfeinerungsmeetings möchten Sie diese Priorisierung vielleicht noch einmal überdenken, aber das bedeutet eher, die Frage zu stellen: „Ist Artikel X immer noch ein Muss?“ Anstatt einen willkürlichen Prozentsatz an Must-Haves, Must-Haves usw. zu haben.
Was Sie sehen sollten, ist eine abnehmende Anzahl von Must-Have-Storys sowohl in Ihren Produkt- als auch in Ihren Sprint-Backlogs, während Sie sich durch das Projekt bewegen. Sobald Sie an dem Punkt angelangt sind, an dem Sie keine Must-Haves mehr in der Warteschlange haben, sollten Sie den Geschäftsinhaber fragen, ob er das Projekt am Ende jedes Sprints als abgeschlossen betrachtet.
Ich bin in einer Organisation, die Scrum-artig ist, wie so viele andere Orte, die von diesem Wasserfall/Traditionellen weggehen und am Ende Agile implementieren wollen.
Wir machen eine ähnliche Priorisierung für alle Iterationsplanungssitzungen, wir haben 15-Tage-Iterationen und nennen Need to Have/Nice to Haves basierend auf den zugesagten Stunden, was absolut höllisch für Burndown und Geschwindigkeit ist, da Sie User Storys/Tasks/Defects haben ständig auf die Veröffentlichung einer nächsten Iteration gestoßen oder in den Rückstand zurückgezogen, um Platz für etwas mit einem höheren "geschäftlichen" Bedarf zu schaffen.
Tun Sie das also nicht, Sie sollten es tun, wenn Sie die Anforderungen fertig stellen und sie während Ihrer Domain-Walk-/Sprint-Planungsmeetings im Backlog positionieren
Das ist zu feinkörnig. Die Akzeptanzkriterien sollten nur von Must-Haves abhängen.
Es kann in Ordnung sein, auch „Stretch“-Ziele zu haben, je nachdem, wie Sie das Sprint-Ziel definieren und Elemente aus dem Produkt-Backlog auswählen.
Beispiel: Wenn das Sprint-Ziel „Funktionalität X implementieren“ lautet, dann sind die Stories und das AC streng auf das für die Implementierung der Funktionalität X erforderliche Minimum beschränkt. Wenn es jedoch verwandte kleine Aufgaben im Produkt-Backlog gibt, die (gemäß der PO) würde X schöner machen oder eine eng verwandte Funktionalität Y implementieren, die X einen Mehrwert verleihen würde, dann denke ich, dass es in Ordnung ist, sie zum Zeitpunkt der Sprintplanung zu identifizieren, sie bei der Arbeit im Hinterkopf zu behalten und sie in den Sprint zu ziehen, wenn und wann a ) Sie haben alle geplanten Sprintaufgaben abgeschlossen b) Sie haben noch genügend Zeit, um die Dehnungsaufgabe zu bewältigen.
Dies könnte eher ein Scrum-Ban-Ansatz sein, nehme ich an.
Das heißt, es wird Ihre Geschwindigkeitsberechnungen durcheinander bringen. Wenn Ihnen das also wichtig ist, tun Sie es nicht. (Auch wenn Sie die hinzugefügten Story Points berücksichtigen, wenn Sie sie hinzufügen, gibt es einen methodischen Unterschied zwischen „wir versuchen X Punkte in Y Tagen und unsere Geschwindigkeit war X/Y“ und „wir versuchen X Punkte in Y Tagen und sind früher fertig, also Wir haben uns weitere Z-Punkte vorgenommen, weil wir sicher waren, dass wir es schaffen würden, woohoo.)
Das vorzeitige Beenden eines Sprints ermöglicht es dem Team auch, diese Zeit zu nutzen, um technische Schulden aufzuholen und andere Nicht-Sprint-Arbeiten zu erledigen, die ihren eigenen Wert haben.
Alan Larimer
Sarow
Alan Larimer