Als ich im Scrum-Board über Blocker sprach, wurde mir klar, dass wir möglicherweise voneinander abhängige Aufgaben haben. Beispielsweise ist das Datenbankdesign von einigen Aktivitäten im UX-Flow abhängig. Oder vielleicht gibt es eine spätere Erkenntnis, dass ein Modul ein anderes Modul erfordert, um abgeschlossen zu werden.
Im Idealfall sollte das nicht passieren, aber nichts ist ideal. Stellen Sie sich vor, Entwickler A arbeitet während des Sprints an Aufgabe 1, die vom Abschluss von Aufgabe 2 abhängig ist. Aufgabe 2 ist Teil desselben Sprints. Also haben wir in einem solchen Fall im Grunde genommen die Anzahl der parallelen Aufgaben im Sprint reduziert.
Wie sollten wir in einem solchen Fall mit Aufgabe 1 umgehen? Soll ich sie gleich aus dem Scrum-Board entfernen und durch eine andere Aufgabe ersetzen? Oder soll ich es einfach im Sprint bleiben lassen, bis der nächste Sprint beginnt? Was ist, wenn es mehr als eine solche Aufgabe im Sprint gibt?
Ich denke, die Frage, die Sie stellen, weist eher auf ein Problem hin, wie Sie Ihre Geschichten / Aufgaben / Arbeitsaufgaben / was auch immer aufteilen und wie sie geschrieben werden. Anstatt zu versuchen, die Symptome dieses Problems zu lösen, ist es meiner Meinung nach sinnvoller, hier das Grundproblem anzugehen. Natürlich gibt es manchmal technische Abhängigkeiten zwischen Geschichten.
Arbeitsaufgaben schreiben
Einer der wichtigsten Teile von Scrum ist das Schreiben von User Stories, die vertikal und nicht horizontal aufgeteilt sind . In der Praxis bedeutet dies, dass jede User Story einen vollständigen Teil der Funktionalität abdecken sollte, von der Datenbank bis zur Benutzeroberfläche. Im Allgemeinen sollten Sie es vermeiden, separate Arbeitselemente für verschiedene Ebenen der Anwendung zu schreiben. Wenn Sie Arbeitselemente vertikal aufteilen, können Sie besser abschätzen, an wie vielen Aufgaben Sie parallel arbeiten können (natürlich unter Einhaltung Ihres WIP-Limits) und dem Team eine bessere Möglichkeit geben, abzuschätzen, was es erledigen kann.
Workitems aufteilen
Beim Aufteilen von Arbeitselementen in Scrum schlägt Mike Cohn vor, Stories auf 5 Arten aufzuteilen (ich habe sie hier in meiner bevorzugten Reihenfolge aufgeführt und nicht in der Reihenfolge, in der er sie auflistet):
Sie werden feststellen, dass keine dieser Methoden besagt: „Trennen Sie die Datenbankarbeit von der API-Schichtarbeit von der UI-Arbeit“. Horizontales Slicing in Scrum ist ein Anti-Pattern und sollte vermieden werden.
Technische Abhängigkeiten zwischen Geschichten
Vermeiden Sie horizontale Schnittgeräusche, basierend auf Ihrer ursprünglichen Frage, als ob dies Ihrem Team helfen sollte, das Problem zu lösen, mit dem Sie konfrontiert sind. Allerdings steht jedes Team vor dem Problem der technischen Abhängigkeiten zwischen den Stories. „Ich muss Benutzer erstellen, bevor ich sie aktualisieren oder löschen kann“, wenn Sie beispielsweise die verschiedenen CRUD-Funktionalitäten aufteilen. In diesem Fall ist die effektivste Strategie, die ich gefunden habe, einfach Ihren Product Owner wissen zu lassen, dass es technische Abhängigkeiten zwischen verschiedenen User Stories gibt und dass er oder sie entsprechend priorisieren sollte.
Ich hoffe das hilft!
Ihre Scrum-Implementierung leidet unter einer Reihe von Framework-Anti-Patterns, die unten im Abschnitt „Analyse “ detailliert beschrieben werden . Diese Prozessprobleme können im Allgemeinen gelöst werden durch:
Die empfohlenen Lösungen werden im Abschnitt „ Empfehlungen “ im Anschluss an die Analyse ausführlich beschrieben.
Stellen Sie sich vor, Entwickler A arbeitet während des Sprints an Aufgabe 1, die vom Abschluss von Aufgabe 2 abhängig ist. Aufgabe 2 ist Teil desselben Sprints. In einem solchen Fall haben wir also im Grunde die Anzahl der parallelen Aufgaben im Sprint reduziert ... Soll ich sie [die Aufgabe] einfach im Sprint bleiben lassen, bis der nächste Sprint beginnt?
Ihre Frage, wenn sie als Ganzes genommen wird, enthüllt eine Reihe von Framework-Implementierungsgerüchen. Zu diesen Antimustern gehören:
Möglicherweise haben Sie auch Product Backlog Items, die die INVEST-Kriterien nicht erfüllen .
Indem Sie sich auf die Geschwindigkeit als Maß dafür konzentrieren, wie gut das Entwicklungsteam arbeitet, haben Sie auf jeden Fall ein X/Y-Problem geschaffen, bei dem die Fähigkeit des Teams, Story Points durch paralleles Arbeiten zu vervollständigen, wichtiger geworden ist als die Bereitstellung eines zusammenhängenden, funktionsorientiertes Ziel.
Stellen Sie sicher, dass jeder Sprint ein übergeordnetes Sprint-Ziel hat. Dies ist eigentlich eine Anforderung des Frameworks. Der Scrum-Guide sagt:
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.
Während das Entwicklungsteam arbeitet, behält es das Sprint-Ziel im Auge. Um das Sprint-Ziel zu erfüllen, implementiert es die Funktionalität und Technologie. Wenn sich die Arbeit als anders herausstellt als vom Entwicklungsteam erwartet, arbeitet es mit dem Product Owner zusammen, um den Umfang des Sprint Backlog innerhalb des Sprints auszuhandeln.
Ein Sprint, der das Sprint-Ziel erreicht, ist ein Erfolg, unabhängig davon, ob alle für den Sprint geplanten Stories und Aufgaben abgeschlossen sind oder nicht. Ebenso ist ein Sprint, der sein Sprint-Ziel nicht erreicht, gescheitert, unabhängig davon, ob alle Storys und Aufgaben gemäß der Definition of Done abgeschlossen sind oder nicht. Der einzige wirkliche Maßstab für den Erfolg eines Sprints ist also die Erfüllung des Sprint-Ziels; der Rest sind nur beratende Metriken.
Ein Scrum-Team sollte sich selbst organisieren, und das Sprint-Planungsmeeting, das tägliche Standup und andere Ad-hoc-Meetings sind da, um dem Team zu ermöglichen, Abhängigkeiten zu verwalten! Wenn der Scrum Master Abhängigkeiten definiert und Aufgaben verteilt, verstößt das gegen die Grundwerte und Prinzipien von Scrum.
Stattdessen sollte sich das Team darauf konzentrieren, das Sprintziel zu erreichen. Dies geschieht häufig durch die Begrenzung der laufenden Arbeit, anstatt parallele Aufgaben zu erstellen. Dies hilft sicherzustellen, dass Stories für das Sprint-Ziel priorisiert werden und dass das gesamte Team zusammenarbeitet, um jede Story so schnell wie möglich zur Definition of Done zu bringen. Da ein Product Backlog Item (z. B. User Story) entweder erledigt oder nicht erledigt ist, bringt es dem Team keinen Vorteil, Aufgaben parallel zu erledigen, anstatt sich über Stories zu schwärmen, um sie zu Done zu bringen.
Der Scrum Guide sagt auch:
- Es werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden;
- Qualitätsziele nehmen nicht ab; und,
- Der Umfang kann geklärt und zwischen dem Product Owner und dem Entwicklungsteam neu verhandelt werden, wenn mehr erfahren wird.
Es ist also nicht erlaubt, Aufgaben oder Stories ohne die Zustimmung des Product Owners aus dem Geltungsbereich zu nehmen, aber Änderungen, die das Sprint-Ziel dennoch erreichen, können ausgehandelt werden. Wenn die Abhängigkeiten nicht innerhalb der Rahmenrichtlinien geklärt werden können, kann der Product Owner den Sprint abbrechen und das Team an die Sprint-Planung zurückgeben .
Die Geschwindigkeit ist ein Maß für die Teamkapazität , nicht für die Produktivität. Es wird im Allgemeinen verwendet, um die Menge an Arbeit zu begrenzen, die das Entwicklungsteam während der Sprint-Planung in jeden Sprint zieht. Daher weisen Geschwindigkeitsabfälle häufig darauf hin, dass Storys während Planungsmeetings nicht ausreichend zerlegt werden, wenn sie gegen die INVEST-Kriterien verstoßen oder wenn andere Prozessprobleme vorliegen.
Als logische Folge davon dürfen eine einzelne User Story und ihre Teilaufgaben niemals größer als ein einzelner Sprint sein. Ein Grund dafür ist, dass solche Geschichten eigentlich Epen sind, denen eine ausreichende Zerlegung fehlt, um genau geschätzt zu werden. Ein weiterer Grund ist, dass alle Arbeiten, die am Ende eines Sprints unvollständig sind, zur Priorisierung durch den Product Owner zurück in das Product Backlog gestellt und dann für einen zukünftigen Sprint neu geschätzt und neu geplant werden müssen (falls sie überhaupt relevant bleiben).
Die Anleitung hier ist, sich nicht mehr auf den aufgewendeten Aufwand zu konzentrieren , sondern sich stattdessen auf die bereitgestellten Funktionen zu konzentrieren. In agilen Frameworks ist ein Arbeitsinkrement das primäre Erfolgsmaß. Wenn Sie es auf andere Weise messen, verstoßen Sie gegen die Grundprinzipien des Frameworks und müssen Ihr Scrum-Team oder die Geschäftsleitung möglicherweise erneut über die Grundprinzipien des Frameworks aufklären.
Todd A. Jacobs