Umgang mit neuen Vorschlägen zu gelösten User Stories im geschlossenen Sprint

In einem Projekt, das mit dem Scrum-Framework verwaltet wird, habe ich eine Situation, in der alle Aufgaben, die mit einer User Story (Feature) verbunden sind, erfolgreich erledigt wurden. Es sind keine weiteren Codeänderungen zulässig, da die Tests im Gange sind und der Sprint kurz vor dem Abschlussdatum steht. Beim Testen und Bewerten des Produkts kamen jedoch ich, der Produktbesitzer oder andere Teammitglieder mit einigen Vorschlägen zu derselben Geschichte.

Wie geht man mit diesen Vorschlägen um?

  • Sollen im neuen Sprint neue Aufgaben erstellt und mit der Story im vorherigen Sprint verknüpft werden?
  • Oder soll im neuen Sprint eine neue Story mit neuen Aufgaben entstehen?
  • Oder gibt es eine bessere Praxis für ein solches Szenario?!

Antworten (2)

Ich erstelle lieber eine neue Story, die dann ins Backlog kommt. Die Geschichte ist normalerweise so:

„Wenn ich [Funktion, die wir im aktuellen Sprint erstellt haben] verwende, möchte ich in der Lage sein, [x] zu tun.“

Beachten Sie, dass ich gesagt habe, dass es in den Rückstand geht und nicht unbedingt in den nächsten Sprint. Es ist etwas Neues und muss gegenüber allem anderen bereits im Rückstand priorisiert werden.

Neue Dinge sind neue Dinge, die neue Dinge sind. Sie gehen alle an denselben Ort, egal wann man an sie dachte.

Ich möchte ausdrücklich mit den Kommentaren dazu in den allgemeinen Rückstand gehen. Dinge, an denen Sie gerade arbeiten, scheinen immer eine höhere Bedeutung zu haben als alles andere. Sie müssen diese Dinge in das Backlog stellen und dann das gesamte Backlog neu priorisieren, nicht nur diese neuen Elemente automatisch in den nächsten Sprint stellen.
Sollte die Priorität nicht auch berücksichtigen, dass der Bearbeiter nachholen muss, wenn zwischen der ersten Implementierung und den neuen Änderungen zu viel Zeit vergeht? Es scheint, als könnte dieser Prozess möglicherweise die Dynamik ersticken.
Ich glaube nicht. Die Priorität sollte auf den Bedürfnissen des Product Owners basieren, nicht auf der Bequemlichkeit der Entwickler. Die Idee ist, die Software zu liefern, die sie wollen, nicht die Software, die für uns einfach zu machen ist. Obwohl ich sagen würde, dass es etwas ist, auf das der Product Owner aufmerksam gemacht werden muss.
@jmort253 Der Kontextwechsel kann sich auf die während der Sprint-Planung zugewiesene Story-Point-Schätzung auswirken, ist jedoch unabhängig von der Priorität einer Story im Product Backlog.

Wenn Sie Scrum folgen, gibt es zwei Möglichkeiten:

  • Der Product Owner beendet den Sprint und die Änderungen werden neu bewertet und neue User Stories erstellt

  • Die neuen Ideen werden zu User Stories für den nächsten Sprint

Außerdem schlage ich einen Rückblick auf das Thema vor, denn wie kommt es, dass die neuen Ideen beim Planungstreffen nicht bekannt sind? Es scheint, dass sich im Hintergrund etwas ändert oder nicht klar ist, was bald behoben werden muss.

Auch wenn es verlockend ist, ändern Sie keine festgeschriebene User Story. Es wird Ihnen zu viel Ärger bereiten und der Broken-Window-Effekt wird einsetzen: Es wird eine weitere kleine Änderung geben, dann noch eine, noch eine ... (und es gibt keine kleine Änderung)

+1 für den Verweis auf den Broken-Window-Effekt, da er das Problem beim Ändern einer engagierten User Story perfekt beschreibt.
Umgang mit neuen Vorschlägen zu gelösten User Stories im geschlossenen Sprint
AntwortenHierDatenschutz-Bestimmungen1y, 0v