it-swarm.com.de

Verwirrt über das Ändern des Sprint-Backlogs während eines Sprints

Ich habe in letzter Zeit viel über Scrum gelesen und festgestellt, dass mir widersprüchliche Informationen darüber vorliegen, 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 ebenfalls. Auch mein Professor für Softwareentwicklung lehrte das Gleiche bei einem Überblick über Scrum.

Ich las jedoch Scrum und XP aus den Gräben und das beschreibt einen Abschnitt für ungeplante Elemente auf dem Taskboard. Also habe ich das Scrum Guide) nachgeschlagen und es heißt, dass während des Sprints "Es werden keine Änderungen vorgenommen, die sich auf das Sprintziel auswirken würden" und in der Diskussion über das Sprintziel "Wenn sich herausstellt, dass die Arbeit anders ist als vom Entwicklungsteam erwartet, arbeiten sie mit dem zusammen Product Owner, um den Umfang des Sprint-Backlogs innerhalb des Sprints auszuhandeln. "In der Diskussion des Sprint-Backlogs heißt es weiter:

Das Sprint Backlog ist ein Plan mit genügend Details, damit Änderungen im Fortschritt im Daily Scrum verstanden werden können. Das Entwicklungsteam ändert das Sprint-Backlog während des Sprints, und das Sprint-Backlog entsteht während des Sprints. Diese Entstehung tritt auf, wenn das Entwicklungsteam den Plan durcharbeitet und mehr über die Arbeit erfährt, die zur Erreichung des Sprint-Ziels erforderlich ist.

Wenn neue Arbeiten erforderlich sind, fügt das Entwicklungsteam sie dem Sprint-Backlog hinzu. Sobald die Arbeit ausgeführt oder abgeschlossen ist, 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, und es gehört ausschließlich dem Entwicklungsteam.

An diesem Punkt bin ich also insgesamt verwirrt. Wenn ich darüber nachdenke, ist es für mich sinnvoller, den zweiten Ansatz zu wählen. Die einzelnen, spezifischen Elemente im Backlog scheinen mir nicht das Wichtigste zu sein, sondern das Sprintziel. Daher ist es sinnvoll, das Sprintziel nicht zu ändern, sondern den Backlog ändern zu können. Wenn zum Beispiel sowohl der Produktbesitzer als auch das Team dachten, sie wären über eine Geschichte auf derselben Seite, aber im Verlauf des Sprints stellten sie fest, dass es ein Missverständnis gab, erscheint es sinnvoll, die Aufgaben, aus denen diese Geschichte besteht, entsprechend zu ändern . Oder wenn es eine Geschichte oder Aufgabe gab, die vergessen wurde, aber erforderlich ist, um das Sprintziel zu erreichen, würde ich denken, dass es am besten ist, die Geschichte oder Aufgabe während des Sprints zum Rückstand hinzuzufügen.

Es gibt jedoch viele Leute, die ziemlich fest davon überzeugt sind, dass eine Änderung des Sprint-Rückstands nicht in Ordnung ist. Verstehe ich diese Position irgendwie falsch? Definieren diese Leute den Sprint-Rückstand irgendwie anders? Mein Verständnis des Sprint-Rückstands ist, dass er sowohl aus den Geschichten 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 herauszufinden, was der idealistische Scrum-Ansatz ist, um das Sprint-Backlog während eines Sprints zu ändern, und ob Leute, die Scrum erfolgreich für die Entwicklung verwenden, das Ändern des Sprint-Backlogs während eines Sprints zulassen.

14
Maltiriel

Erstens hätte ich keine harten Regeln dafür; Der springende Punkt beim Scrum ist, dass Sie sich an die Situation anpassen können. Sie sollten also in der Lage sein, das Sprint-Backlog während des Sprints zu ändern, wenn Sie dies unbedingt müssen (als hätten Sie etwas Kritisches vergessen).

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

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

  1. Füge dem Sprint einen neuen Gegenstand hinzu.
    ABER entferne einen Gegenstand gleicher Größe aus dem Sprint.
  2. Löschen Sie den schlecht geplanten Gegenstand aus diesem Sprint (damit Sie ihn im nächsten Sprint richtig planen können).
    • Hinzufügen einer Alternative (geeigneter Größe) vom oberen Rand des Produkt-Backlogs (die von Ihrem Sprint-Planungsmeeting in der Prioritätsreihenfolge sein sollte).
    • Oder wenn alle Sprint-Elemente fertig sind, lassen Sie die 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 die Situation berücksichtigen, in der außergewöhnliche Umstände auftreten können. In den meisten Fällen würde ich mich für Option 2 entscheiden und die Entwickler mit Aufgaben aus dem Backlog die Lücke schließen lassen.

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

Denken Sie daran, dass der Sprint kurz ist und nur die Markierung des nächsten Abfalls nicht das Ende des Entwicklungszyklus. Der Produktbesitzer müsste sehr verzweifelt nach einer Funktion suchen, die er nicht auf das Ende des nächsten Sprints warten kann.

10
Martin York

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

Das Sprint Backlog verfügt über zwei Detailebenen. Erstens ist es eine Liste von Elementen (User Stories), zu deren Bereitstellung sich das Team verpflichtet hat. Zweitens sind es alle AUFGABEN, die das Team beabsichtigt, um jede dieser Geschichten zu liefern.

Wenn Leute über das Sprint Backlog sprechen, sollten sie wirklich klar sein, was sie meinen. Wenn Sie das Scrum-Handbuch lesen, werden Sie feststellen, dass darin Folgendes angegeben ist: Das Sprint-Backlog besteht aus den für den Sprint ausgewählten Product Backlog-Elementen sowie einem Plan für die Bereitstellung des Produktinkrements und die Verwirklichung des Sprint-Ziels.

Es ist also sowohl die Liste der Product Backlog-Elemente als auch der Plan (Aufgaben), um sie zu liefern.

Jetzt möchten viele Teams alle vorgeschlagenen Aufgaben (Plan) zu Beginn des Sprints hinzufügen, damit sie ein Burndown-Diagramm basierend auf den verbleibenden Stunden verfolgen können. Andere Teams lassen die Aufgaben nach Bedarf entstehen. In diesem Fall ist es in Ordnung, das Sprint-Backlog zu erweitern, da das Team dies tun muss, um die Artikel zu überprüfen und anzupassen, um sie zu liefern und 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 (sollte bereits priorisiert und dimensioniert sein) das Product Backlog ... aber nur, wenn sie das Vertrauen haben, dass es innerhalb dieses Sprints abgeschlossen wird und mit dem Sprint-Ziel übereinstimmt.

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

Ich hoffe das klärt die Situation.

10
B. F. Clark

Es hängt von Ihren Situationen ab. Wenn einige Informationen während der Planung fehlen und Sie später herausfinden, dass Sie einige Storys ändern oder einige Punkte hinzufügen müssen, ist das 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.

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

2
Kumar Bibek

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

Grabe deine Fersen früh ein. Diejenigen, die nach einer Änderung fragen, müssen auf die harte Tour lernen, sonst planen Sie, wertlos zu sein, wenn die Leute lernen, dass Sie tun können, was Sie wollen.

Zitieren Sie, dass Qualität vom Fokus und Fehler vom Fallenlassen eines Gedankengangs herrührt. Nennen Sie die Kosten für die Kontextumschaltung. Das Verfolgen von Schulden und das Management des Schreibens, Diskutierens und Einspielens einer Geschichte, um halbherzige Arbeit anzusprechen, ist kostspielig. Beginnen Sie diesen Weg einfach nicht.

Idee: Geben Sie dem Management 3 Switch-Credits, um jedes Quartal als Kompromiss auszugeben.

0
Luke Puplett