Wie ändern Sie eine gelieferte User Story?

TL;DR

Wenn Sie eine User Story in einem früheren Sprint liefern und sie dann in einem neuen Sprint ändern müssen, was tun Sie?

Du nicht. Alle Arbeiten müssen vom Product Owner im Product Backlog priorisiert werden, und es sollten keine ungeplanten Stories in die aktuelle Iteration eingeführt werden, nachdem die Sprint-Planung abgeschlossen ist.

Wenn Sie Arbeit entdecken, die in einem zukünftigen Sprint erledigt werden muss, schreiben Sie eine neue User Story und reichen Sie sie dem Product Owner zur Aufnahme in das Product Backlog ein. Wenn es wirklich ein Show-Stopper ist, der den Fortschritt innerhalb des aktuellen Sprints blockiert, sprechen Sie das Problem innerhalb des Teams an (z. B. während des täglichen Stand-Ups) und lassen Sie es vom Scrum Master eskalieren.

Refactoring vs. New Work und Rework

Refactoring ändert nicht das Verhalten eines Features, sondern nur die interne Implementierung. Möglicherweise müssen Sie vorhandenen Code umgestalten, um ein neues Feature aufzunehmen, aber der alte Code sollte sich grundsätzlich genauso verhalten , und alle Ihre alten Tests sollten weiterhin bestehen.

Darüber hinaus sollten solche Refactorings auf das absolute Minimum beschränkt werden, das zur Anpassung an die neue Funktion erforderlich ist. Dies ist nicht der Zeitpunkt, um zurückzugehen und Verbesserungen oder Optimierungen vorzunehmen, die über den Rahmen der Story hinausgehen, an der Sie gerade arbeiten.

Wenn Sie das Verhalten ändern, eine Benutzeroberfläche verbessern oder einen Codeabschnitt optimieren müssen, ist das neue Arbeit . Es muss dem Product Backlog hinzugefügt werden, vom Product Owner während der Backlog-Pflege priorisiert werden und dann während der Sprint-Planung für einen zukünftigen Sprint und nicht für den aktuellen zum Sprint-Backlog hinzugefügt werden.

Ausnahmen gibt es immer

Von jeder Regel gibt es Ausnahmen. Einige Beispiele sind:

1. Neue Arbeit, die für das aktuelle Sprint-Ziel wesentlich ist, kann während eines Sprints entdeckt werden und könnte eine vorzeitige Beendigung und eine Rückkehr zur Sprint-Planung rechtfertigen.
2. Technische Schulden zu begleichen, wenn man keine anderen Storys hat, an denen man arbeiten kann, ist eine gute Zeitverwendung.
3. Etwas im Vorbeigehen umzugestalten (oder sogar zu verbessern), während man an einem zu liefernden Feature arbeitet, ist in der Praxis oft in Ordnung, aber es ist ein sehr schmaler Grat, der oft zu Yak-Rasur führt und Ressourcen von Stories wegnimmt, denen sich das Team für den Sprint verschrieben hat. Tu das nicht.
4. Stories, die sich nicht auf dem kritischen Pfad zum Sprint-Ziel befinden, können mit aktiver Mitarbeit des Product Owners ausgetauscht, modifiziert oder de-scoped werden, ohne eine vorzeitige Beendigung auszulösen. Dies ist eine fortschrittliche Technik, die leicht nach hinten losgehen kann, also verlassen Sie sich nicht darauf.

Scrum und andere agile Frameworks sollen keine Zwangsjacke sein. Das System bietet genügend Flexibilität, um Variationen und Randfälle aufzunehmen. Ein Team muss jedoch wirklich die zugrunde liegenden Prinzipien beherrschen, bevor es versucht, gegen Prinzipien wie YAGNI zu verstoßen oder formelle Scoping-Kontrollen zu umgehen, sonst riskiert es, sein Framework in ScrumBut oder sein fehlerverursachendes Äquivalent zu verwandeln.