Sollten wir Story Points einer Aufgabe, die wir begonnen, aber im letzten Sprint nicht beendet haben, erneut schätzen (reduzieren)? [Duplikat]

Letztendlich liegt es am Team, aber ich denke, es hängt genau davon ab, wie Sie Punkte verwenden. Eine Regel, die ich gerne verwende, wenn eine Story nicht zu 100 % fertig ist, ist, sie als null Punkte für die Geschwindigkeit des aktuellen Sprints zu zählen. Wenn Sie dies tun, würde ich vorschlagen, die Punkte unverändert zu lassen, wenn Sie die Story in den nächsten Sprint einfügen. Der Effekt davon wird sein, dass im aktuellen Sprint ein Geschwindigkeitsabfall, aber im nächsten Sprint ein entsprechender Anstieg angezeigt wird, was sinnvoll erscheint.

Obwohl ich das Argument für Pragmatismus verstehe oder das Team entscheiden zu lassen, würde ich absolut raten, dass Sie dieselbe 13-Punkte-Geschichte auf den nächsten Sprint übertragen. Bei Scrum geht es darum, Produktinkremente zu liefern, nicht um Arbeit. Das mag wie eine dumme Aussage erscheinen, weil Sie sicherlich die Arbeit leisten müssen, um das Inkrement zu liefern, aber es geht darum, worauf Sie den Fokus legen.

Schauen wir uns also die Frage in dieser Linse an. Wenn wir die Geschichte aufteilen, geht es darum zu zeigen, dass Arbeit geleistet wurde. Aber es verschleiert die Tatsache, dass kein Inkrement des Produkts geliefert wurde. Andererseits wird beim Übertragen der Geschichte das Kästchen "Erledigt" nur dann aktiviert, wenn das Inkrement geliefert wird, unabhängig davon, wohin die Arbeit gegangen ist. Welche erfüllt also tatsächlich die Absicht von Scrum?

Darauf gibt es nun eine differenzierte dritte Antwort. Nehmen wir an, wir haben noch 2 Tage im Sprint und es ist klar, dass dieses eine Backlog-Element nicht abgeschlossen wird. In diesem Moment stimmen wir also mit dem PO überein, dass wir einen Teil des Features in einem potenziell veröffentlichbaren Zustand (QA, bereitstellbar usw.) liefern könnten, wenn wir überhaupt nicht an einem anderen Teil arbeiten, und alle sind sich einig, dass dies geschäftlich sinnvoll ist . Jetzt haben wir tatsächlich einen Teil dieser 13-Punkte-Geschichte geliefert, und es macht Sinn, es als erledigt zu bezeichnen und den Rest in den nächsten Sprint zu verschieben. Sie könnten dann beide Geschichten neu bewerten, wenn Ihnen das im Team einen gewissen Wert verschafft.

Es gibt keine beste Option; du kannst es so oder so machen. Entscheiden Sie hier am besten gemeinsam mit Ihrem Team, anstatt sich mit einer Stimme sagen zu lassen „das machen wir so“.

So sehe ich das, andere verwenden möglicherweise unterschiedliche Ansätze, je nachdem, wie sie die Geschwindigkeit verwenden.

Geschwindigkeit ist etwas, das den Fortschritt pro Sprint anzeigen sollte, nicht die Arbeit pro Sprint. Wenn Sie die Story Points aufteilen, messen Sie die Arbeit, nicht den Fortschritt. Die User Story „Fertig“ bedeutet Fortschritt, halb fertig ist nicht wirklich Fortschritt, denn in Agile wird Fortschritt in funktionierender Software gemessen, nicht in Prozent der abgeschlossenen Arbeit.

Wenn Sie also die Story Points aufteilen, zeigt Ihr aktueller Sprint mehr Fortschritt als tatsächlich erreicht. Für Zukunftsprognosen könnte dies eine optimistischere Sicht auf das geben, was Sie tun können. Es scheint, dass Sie mehr getan haben, aber tatsächlich ist etwas in den nächsten Sprint übergelaufen. Eine kleinere Geschwindigkeit wird die Tatsache berücksichtigen, dass dies in Zukunft erneut auftreten kann, sodass die Geschwindigkeitsmessung besser mit der Realität übereinstimmt (zumindest sehe ich das so).

In Ihrem nächsten Sprint schätzen Sie die Geschichte neu ein, was noch zu tun ist, und das Beenden dieser Arbeit wird sich in der Geschwindigkeit dieses nächsten Sprints als "erledigt" widerspiegeln.

Insgesamt machst du mehr oder weniger die gleiche Arbeit, aber die Geschwindigkeit wird den „Schluckauf“ in diesem Sprint widerspiegeln.