it-swarm.dev

Was tun bei Agile, wenn eine User Story nicht in einer Iteration abgeschlossen wird?

Verschieben Sie die Story einfach in eine neue Iteration oder verzögern Sie die nächste Iteration?

Es wird etwas schwierig, wenn Sie etwas wie Jira verwenden, wenn Sie Geschichten zwischen Iterationen kopieren oder verschieben müssen, da dies Berechnungen von Geschwindigkeit/Punkten usw. bewirkt.

Gibt es eine Best Practice?

16
codecompleting

Nach meinen Erfahrungen werden Geschichten entweder gemacht oder nicht gemacht. Es gibt kein Konzept für eine unvollendete Geschichte. Am Ende eines Sprints haben Sie entweder das Design, die Implementierung, das Testen, die Integration und das Systemtest für eine Story abgeschlossen und sie dem Kunden zur Abmeldung vorgelegt. Zu diesem Zeitpunkt wurde sie aus dem Rückstand entfernt oder blieb in der Rückstand für den nächsten Sprint. Es gab kein Konzept für eine Neubewertung oder teilweise abgeschlossene Geschichten.

Zu Beginn der nächsten Iteration wurde eine N-Punkt-Story, die in der vorherigen Iteration gestartet und unvollendet gelassen wurde, immer noch als N-Punkt-Story betrachtet. Unsere Geschwindigkeit für den vorherigen Sprint wurde verwendet, um eine angemessene Anzahl von Story-Punkten für den nächsten Sprint abzurufen, beginnend mit den N unfertigen Punkten und den obersten Storys, bis die Anzahl der Story-Punkte in der Iteration die Geschwindigkeit der vorherigen Punkte war.

Dies war jedoch nur unsere Praxis. Der Schlüssel ist, konsistent zu sein. Was auch immer Sie wählen, tun Sie dies bei jeder Iteration und ändern Sie es nicht - dies wirkt sich darauf aus, wie Sie die Geschwindigkeit berechnen und die Arbeit für zukünftige Sprints schätzen.

21
Thomas Owens

Die Iterationsgröße ist angeblich festgelegt. Der beste Ansatz (meiner Meinung nach :)) ist das Teilen. Wenn Aufgaben innerhalb der Iteration, der sie zugewiesen sind, nicht abgeschlossen sind, empfehle ich normalerweise, die User Stories aufzuteilen und die unvollständigen Aufgaben in die nächste Iteration zu verschieben. Die Schätzung der neuen User Story wird aus den verbleibenden Einheiten berechnet, die zur Vervollständigung der ursprünglichen User Story erforderlich sind. Auf diese Weise können Sie die Schätzungen beibehalten und auch historische Referenzen pflegen.

8

Verschieben Sie die Geschichte zur nächsten Iteration. Aktualisieren Sie möglicherweise die Größe, wenn eine angemessene Menge an Arbeit daran geleistet wurde.

8
Alec Munro

A. Fügen Sie die Geschichte in den Projektstau ein. Wenn es immer noch das Wichtigste ist, wird es für den nächsten Sprint geplant. Wenn nicht, plant der Product Owner etwas Wertvolleres.

B. Für diesen Sprint erhalten Sie für diese Geschichte keine Punkte. Wenn Sie den nächsten Sprint planen, zählen Sie nur Punkte für Storys, die diesen Sprint abgeschlossen haben. (Ja, Sie werden am Ende des nächsten Sprints eine Bonusgeschichte einspielen. Großartig. Aber es ist besser, eine Bonusgeschichte zu bekommen, als anzunehmen, dass Sie sie fertig haben, dann müssen Sie eine weitere unvollendete Geschichte erklären .)

6
Sean McMillan

Sie können die Story zur nächsten Iteration verschieben und erneut schätzen. Sie können jederzeit mit dem Product Owner/Team und dem Scrum Master besprechen, was zu tun ist.

3
Daan Geurts

Das Dilemma: Wohin gehen Story Points für unvollendete Storys? Der Sprint, wo sie fertig sind? Teilgutschrift in jedem Sprint für den Teil, der in jedem Sprint beendet wurde? So habe ich das Dilemma in einem Blogbeitrag beantwortet:

Diese Punkte gehen nirgendwo hin. Kein Kredit. Aber das Team muss die Arbeit abschließen.

Vollständiger Blog zu diesem Thema hier: http://agileangle.blogspot.com/2011/07/story-points-who-gets-credit.html

3
David Babicz

Neben anderen Antworten könnten Sie

1) Erstellen Sie eine Story, um die abgeschlossene Arbeit darzustellen, und eine neue für die verbleibende Arbeit, wobei Sie die Schätzungen anpassen.

2) analysieren, warum es eine falsche Schätzung gab. Geschichten stellen normalerweise Verpflichtungen dar, und wenn eine Verpflichtung nicht erfüllt wurde, ist sie irgendwie schlecht. Gab es im Vorfeld nicht genügend Analysen (d. H. Entwickler wussten nicht, wie viel Arbeit es tatsächlich sein würde), wurden die Leute krank, verhinderten andere Fehler, dass die Arbeit erledigt wurde usw.?

2
hvgotcodes

Wenn die Geschichte nicht vollständig ist (gemäß Ihrer Definition von erledigt), sollten Sie keine Punkte davon erhalten.

Erstellen Sie im nächsten Sprint eine neue Story basierend auf den Resten der unvollendeten, fügen Sie sie dem Sprint-Backlog hinzu und schätzen Sie sie. Mögliche Zusammenführung mit einer anderen Geschichte, wenn sie zu klein ist.

Wenn Ihr Werkzeug damit nicht umgehen kann, sollten Sie wahrscheinlich nach etwas suchen, das dies kann. Ich bevorzuge Low-Tech-Tools mich.

2
Martin Wickman

Wir neigen dazu, Geschichten zu bremsen, damit sie leicht in einen Sprint passen und leicht entfernt werden können. Es bedarf einer bestimmten Denkweise, um die Geschichte während des Sprint-Planungstreffens in lieferbare Teile zu zerlegen.

Die Sache, die ich auch gefunden habe, ist, dass mein Team die ganze Arbeit am Kofferraum erledigen kann, wenn die Geschichten in lieferbare Teile zerfallen (die sichtbar sein können oder nicht oder sogar für ein paar Sprints ausgeschaltet sind), ohne Probleme damit zu haben Arbeiten Sie an einem Zweig und führen Sie die Arbeit später erneut durch, was immer schmerzhaft ist. Das ist also ein Bonus.

0

Wir variieren einige der gegebenen Antworten.

Sie schätzen einen Sprint auf eine bestimmte Anzahl von Punkten, sagen wir 34. Wenn wir den festgelegten Endpunkt für den Sprint erreicht haben und noch nicht fertig sind, starten wir einen Abhilfesprint.

Was dies bedeutet ist:

  1. Wir bekommen Gutschrift für die 34 Punkte.
  2. Wir müssen die Geschichte beenden, an der wir gearbeitet haben. Es war zum Zeitpunkt der Zuweisung die höchste Priorität im Backlog, daher wird diese Priorität beibehalten.
  3. Wir beauftragen und arbeiten an der gegebenen Geschichte, bis wir unsere Definition von erledigt erfüllt haben. Dieser Zeitspanne werden 0 Story-Punkte zugewiesen. Dies dient dazu, unsere Geschwindigkeit anzupassen.
0
drneel
  1. Bei der Sprint-Überprüfung trifft der Product Owner in Absprache mit dem Sprint-Team und den Stakeholdern die Entscheidung über die Fertigstellung. In diesem Fall erklärt die Bestellung, dass die Story nicht den beabsichtigten Kundenanforderungen entspricht.
  2. Die Bestellung kann sich dafür entscheiden, eine neue Story zu erstellen und diese in den Rückstand Produkt zu stellen. Die neue Geschichte basiert wie jede andere Geschichte auf den Informationen, die die Bestellung über den aktuellen Status des Produkts und die aktuellen Bedürfnisse des Kunden hat. Dies schließt offensichtlich die Diskussion ein, die über die oben rückgängig gemachte Geschichte stattgefunden hat.
  3. Beim nächsten Planungstreffen wird die neue Geschichte wie jede andere bewertet. Die Bestellung priorisiert und das Team schätzt den Aufwand.

Anmerkungen:

  1. Der Grad der Fertigstellung ist ein Faktor im Entscheidungsprozess. Wenn das Team beispielsweise zustimmt, dass es "eine Stunde" nach Fertigstellung ist, kann die Bestellung zustimmen, die getroffene Entscheidung zu verzögern. Aber das Team muss noch zeigen, dass die Geschichte fertig ist!
  2. In meinem Team ist eine Geschichte nach dieser Sprint-Überprüfung niemals verschoben aus dem Sprint (sie ist so wie sie ist geschlossen). Wir verwenden die Rate "erledigt", um sie während der Retrospektive als Gesprächsthema zu verwenden. Wenn wir die Geschichte verschieben würden, würde es so aussehen, als ob unsere Fertigstellungsrate bei jedem Sprint 100% betrug.
0
GuyR