Ich habe mit Teams gearbeitet, die bei der Verwendung von Scrum von dieser Meinung abgefallen sind: Jede Story muss am Ende des Sprints abgeschlossen sein.
Was ist die „offizielle“ Definition/Anforderung?
Ich bemühe mich, jede Story bis zum Ende des Sprints fertig zu haben, und erkenne an, dass Storys nicht für untätige Teammitglieder herangezogen werden sollten, wenn nicht genügend Zeit vorhanden ist, um sie abzuschließen, sodass ein Produkt mit vollständiger Funktionalität ideal für die Sprint-Überprüfung ist.
In der realen Welt ist es jedoch fast unmöglich sicherzustellen, dass jedes Teammitglied (in meinem Fall Entwickler) nicht mindestens einen Tag untätig ist, da sich unser Team über 3 sehr unterschiedliche Zeitzonen erstreckt und es praktisch kein einziges "Ende" gibt des Sprints" oder "Sprintstart"-Zeit.
Sie sagen, dass einige Teams Folgendes glauben:
[J]ede Story muss am Ende des Sprints abgeschlossen sein.
Es mag wahr sein, dass einige Teams an dieses weit verbreitete Missverständnis glauben, aber es ist faktisch falsch. Das Scrum-Framework verlangt, dass das Scrum-Team sein Bestes gibt, um in jedem Sprint ein kohärentes Sprint-Ziel zu erreichen. User Stories (oder, kanonischer ausgedrückt, Product Backlog Items) sind eher Mittel zum Zweck als Selbstzweck.
Denken Sie immer daran, dass das Ziel eines Sprints nicht darin besteht, viele Backlog-Elemente zu erledigen. Das Ziel eines Sprints ist es, das Sprint-Ziel zu erreichen .
Der Scrum Guide sagt ausdrücklich (Hervorhebung und Kursivschrift von mir):
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 .
Viele User Stories zu haben, die jeweils als unabhängige Initiativen behandelt werden, die alle bis zum Ende des Sprints abgeschlossen sein müssen, damit der Sprint erfolgreich ist, ist ein Anti-Pattern. Es ist auch laut Scrum Guide ausdrücklich verboten. Es ist sicherlich üblich, dieses Muster in Geschäften zu sehen, die mit der agilen Einführung zu kämpfen haben, aber nur weil es üblich ist, ist es nicht agil (und es ist sicherlich nicht Scrum).
Die Frage ist, ob das Team das Sprintziel noch erreichen kann, wenn bestimmte Geschichten nicht begonnen werden, oder am Ende des Sprints unvollständig bleibt. Die einzige Möglichkeit, dies herauszufinden, besteht darin, das Scrum-Team zu fragen und dann den Fortschritt in Richtung des Sprint-Ziels in Ihrem Burn-Down-Diagramm, Kanban-Board, Sprint-Backlog oder anderen Artefakten zu verfolgen. Der Product Owner hat die Möglichkeit, den Umfang für den Sprint neu auszuhandeln oder den Sprint abzubrechen und zur Sprint-Planung zurückzukehren, wenn das aktuelle Sprint-Ziel gefährdet ist.
Die folgenden Elemente des Scrum-Frameworks sind explizit im Scrum-Leitfaden definiert. Das Sprint-Ziel wird während der Sprint-Planung entwickelt und bietet während des gesamten Sprints Orientierung. Das Inkrement ist die abgeschlossene Arbeit gemäß der Definition of Done und ist im Wesentlichen das De-facto-Lieferergebnis für den Sprint.
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.
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. Es muss sich in brauchbarem Zustand befinden, unabhängig davon, ob der Product Owner entscheidet, es tatsächlich freizugeben.
Auch wenn dies im Scrum Guide nicht speziell angesprochen wird, hat ein Sprint in der Praxis wirklich nur drei Fehlerbedingungen:
Das ist es. Einzelne Geschichten können gemacht oder nicht gemacht werden, Prognosen (Schätzungen) können verpasst werden und das Team hat möglicherweise erfolgreich den falschen MacGuffin geliefert. Solche Sprints sind immer noch technisch „erfolgreich“, da sie ein potenziell veröffentlichbares Inkrement lieferten und das Framework nutzten, um dem Unternehmen Prozesstransparenz und angemessene Möglichkeiten zur Überprüfung und Anpassung zu bieten.
Aziz Scheich