Verwirrt über die Änderung des Sprint-Backlogs während eines Sprints

Ich habe in letzter Zeit viel über Scrum gelesen und festgestellt, dass es für mich widersprüchliche Informationen darüber gibt, ob es in Ordnung ist, den Sprint-Rückstand während eines Sprints zu ändern. Der Wikipedia-Artikel über Scrum sagt, dass es nicht in Ordnung ist, und verschiedene andere Artikel sagen dies auch. Das hat auch mein Professor für Softwareentwicklung während eines Scrum-Überblicks gelehrt.

Ich habe jedoch Scrum und XP aus den Trenches gelesen und darin wird ein Abschnitt für ungeplante Elemente auf dem Taskboard beschrieben. Also habe ich den Scrum-Leitfaden nachgeschlagen und festgestellt, dass während des Sprints "Keine Änderungen vorgenommen werden, die sich auf das Sprint-Ziel auswirken" und in der Diskussion über das Sprint-Ziel "Wenn sich herausstellt, dass die Arbeit anders ist als vom Entwicklungsteam erwartet". Anschließend arbeiten sie mit dem Product Owner zusammen, um den Umfang des Sprint Backlogs im Sprint auszuhandeln. " In der Diskussion des Sprint Backlog heißt es weiter:

Das Sprint Backlog ist ein Plan mit genügend Details, damit Änderungen im täglichen Scrum nachvollzogen werden können. Das Entwicklungsteam ändert das Sprint-Backlog während des Sprints und das Sprint-Backlog entsteht während des Sprints. Diese Entwicklung erfolgt, wenn das Entwicklungsteam den Plan durcharbeitet und mehr über die zur Erreichung des Sprint-Ziels erforderliche Arbeit erfährt.

Wenn neue Arbeiten erforderlich sind, fügt das Entwicklungsteam diese dem Sprint-Backlog hinzu. Während die Arbeit ausgeführt oder abgeschlossen wird, wird die geschätzte verbleibende Arbeit aktualisiert. Wenn Elemente des Plans als unnötig erachtet werden, werden sie entfernt. Nur das Entwicklungsteam kann sein Sprint-Backlog während eines Sprints ändern. Das Sprint-Backlog ist ein gut sichtbares Echtzeitbild der Arbeit, die das Entwicklungsteam während des Sprints ausführen möchte. Es gehört ausschließlich dem Entwicklungsteam.

An diesem Punkt bin ich also völlig verwirrt. Wenn ich darüber nachdenke, ist es für mich sinnvoller, den zweiten Ansatz zu wählen. Die einzelnen, spezifischen Elemente im Rückstand scheinen mir nicht das Wichtigste zu sein, sondern das Sprintziel. Es ist also sinnvoll, das Sprintziel nicht zu ändern, sondern den Rückstand ändern zu können. Zum Beispiel, wenn sowohl der Product Owner als auch das Team dachten, sie wären auf derselben Seite über eine Geschichte, aber als der Sprint voranschritt, stellten sie fest, dass es ein Missverständnis gab, erscheint es sinnvoll, die Aufgaben, die diese Geschichte ausmachen, entsprechend zu ändern . Oder wenn es eine Geschichte oder Aufgabe gibt, die vergessen wurde, aber zum Erreichen des Sprintziels erforderlich ist, ist es meiner Meinung nach am besten, die Geschichte oder Aufgabe während des Sprints zum Rückstand hinzuzufügen.

Es gibt jedoch viele Leute, die ziemlich unnachgiebig scheinen, dass eine Änderung des Sprint-Backlogs nicht in Ordnung ist. Verstehe ich diese Position irgendwie falsch? Definieren diese Leute den Sprint-Rückstand irgendwie anders? Ich verstehe den Sprint-Rückstand so, dass er sowohl aus den Storys als auch aus den Aufgaben besteht, in die sie unterteilt sind.

Auf jeden Fall würde ich mich über Beiträge zu diesem Thema sehr freuen. Ich versuche sowohl herauszufinden, was der idealistische Scrum-Ansatz ist, um den Sprint-Rückstand während eines Sprints zu ändern, als auch, ob Leute, die Scrum erfolgreich für die Entwicklung verwenden, es erlauben, den Sprint-Rückstand während eines Sprints zu ändern.

Zunächst einmal hätte ich keine strengen Regeln. Das Wichtigste ist, dass Sie sich an die Situation anpassen können. Sie sollten also in der Lage sein, den Sprint-Rückstand während des Sprints zu ändern, wenn Sie dies unbedingt tun müssen (als hätten Sie etwas Kritisches vergessen).

Es sollte jedoch widerstanden werden, diese Änderung des Sprint-Rückstandes während des Sprints zu sagen. Der springende Punkt des kurzen Sprints ist, dass neue Arbeiten zum nächsten Sprint hinzugefügt werden können (nachdem sie korrekt priorisiert wurden), ohne dass dies Auswirkungen auf die gesamte Projektzeitlinie hat (mehrere Sprints).

Wenn die Arbeit für eine der Aufgaben in diesem Sprint entscheidend ist, haben Sie zwei Möglichkeiten.

1. Füge einen neuen Gegenstand zum Sprint hinzu.
   ABER entfernen Sie ein gleich großes Objekt aus dem Sprint.
2. Löschen Sie das schlecht geplante Element aus diesem Sprint (damit Sie es im nächsten Sprint richtig planen können).
   • Hinzufügen einer Alternative (von geeigneter Größe) aus dem oberen Bereich des Produkt-Backlogs (sollte in der Prioritätsreihenfolge Ihres Sprint-Planungsmeetings sein).
   • Oder wenn alle Sprint-Elemente fertig sind, können Entwickler die Lücke im Produkt-Backlog schließen.

Ich bin also im Lager, dass Sie den Sprint-Rückstand wahrscheinlich nicht ändern sollten. Sie müssen jedoch berücksichtigen, dass möglicherweise außergewöhnliche Umstände vorliegen. In den meisten Fällen entschied ich mich für Option 2 und überließ es den Entwicklern, die Lücke mit Aufgaben aus dem Backlog zu schließen.

In der nächsten Planungssitzung wird die neue Aufgabe dann entsprechend analysiert und dem Sprint hinzugefügt (sofern zutreffend).

Denken Sie daran, dass der Sprint kurz ist und nur die Marke des nächsten Abfalls und nicht das Ende des Entwicklungszyklus. Der Produktbesitzer müsste sehr verzweifelt nach einer Funktion sein, die er nicht bis zum Ende des nächsten Sprints abwarten kann.

Die Verwirrung ist auf mehrdeutige Sprache zurückzuführen.

Das Sprint-Backlog besteht aus zwei Detailebenen. Erstens ist es eine Liste von Gegenständen (User Stories), zu deren Lieferung sich das Team verpflichtet hat. Zweitens sind es alle AUFGABEN, die das Team zu tun beabsichtigt, um jede dieser Geschichten zu liefern.

Wenn also Leute über das Sprint Backlog sprechen, sollten sie sich wirklich darüber im Klaren sein, was sie meinen. Wenn Sie das Scrum-Handbuch lesen, werden Sie feststellen, dass Folgendes angegeben ist: Das Sprint-Backlog ist der Satz von Product Backlog-Elementen, die für den Sprint ausgewählt wurden, sowie ein Plan für die Bereitstellung des Produktinkrements und die Realisierung des Sprint-Ziels.

So ist es sowohl die Liste der Product Backlog Items als auch der Plan (Aufgaben), um sie zu liefern.

Nun möchten viele Teams alle vorgeschlagenen Aufgaben (Plan) zu Beginn des Sprints hinzufügen, um ein Burndown-Diagramm basierend auf den verbleibenden Stunden zu erstellen. Andere Teams lassen die Aufgaben nach Bedarf entstehen. Dies ist der Zeitpunkt, an dem es in Ordnung ist, das Sprint-Backlog zu erweitern, da das Team dies tun muss, um die Artikel zu prüfen und anzupassen, um das Sprint-Ziel zu erreichen.

Unter bestimmten Umständen kann ein Team dem Zeitplan weit voraus sein und (nachdem alle anderen nützlichen Aufgaben beseitigt wurden, die die Fähigkeiten des Teams verbessern könnten) entscheiden, mit dem Product Owner zusammenzuarbeiten, um eine andere Story auszuwählen (die bereits priorisiert und dimensioniert sein sollte) das Product Backlog ... aber nur, wenn sie die Gewissheit haben, dass es in diesem Sprint abgeschlossen wird und mit dem Sprint-Ziel übereinstimmt.

Da haben wir es also; JA ... Teams fügen dem Sprint Backlog-Plan nach Bedarf Aufgaben hinzu. NEIN, sie werden normalerweise nicht zur Liste der Rückstandselemente hinzugefügt, die den Umfang des Sprints definieren.

Ich hoffe das klärt die Situation.

Es hängt von Ihren Situationen ab. Wenn während der Planung einige Informationen fehlen und Sie später herausfinden, dass Sie einige Storys ändern oder einige Punkte hinzufügen müssen, ist dies meiner Meinung nach in Ordnung. Aber ja, wenn sich der Umfang einer Funktion vollständig ändert, ist dies eine extreme Situation und muss anders gehandhabt werden.

Natürlich wird bei der Planung davon ausgegangen, dass jeder die Funktionen, an denen er arbeiten würde, genau kennt und bespricht. Wenn die Diskussionen und die Planung gut sind, brauchen Sie in fast allen Fällen keine Änderungen.

Ich stimme den Antworten zu. Ich möchte darauf hinweisen, dass die Geschichte, wenn sie begonnen hat, erst gestoppt werden kann, wenn sie fertig ist.

Grabe deine Fersen früh ein. Diejenigen, die nach der Veränderung fragen, müssen es auf die harte Tour lernen, sonst wird die Planung wertlos, wenn die Leute lernen, dass Sie tun können, was Sie wollen.

Zitieren Sie, dass Qualität vom Fokus und von den Programmfehlern kommt, die einen Gedankenzug fallen lassen. Nennen Sie die Kosten für die Kontextumschaltung. Das Aufspüren von Schulden und das Schreiben, Diskutieren und Einspielen einer Geschichte, um sich mit halbgebackenen Arbeiten zu befassen, sind kostspielig. Beginnen Sie einfach nicht auf dieser Route.

Idee: Geben Sie dem Management 3 Wechselkredite, um jedes Quartal als Kompromiss auszugeben.