it-swarm.com.de

Scrum - wie man eine teilweise vollständige User Story auf den nächsten Sprint überträgt, ohne den Rückstand zu verzerren

Wir verwenden Scrum und stellen gelegentlich fest, dass wir eine User Story in dem Sprint, in dem sie geplant war, nicht ganz beenden können. Im echten Scrum-Stil liefern wir die Software trotzdem aus und erwägen, die User Story während der nächsten Sprint-Planungssitzung in den nächsten Sprint aufzunehmen. Wie schätzen wir die User Story, die wir übertragen, in der nächsten Sprint-Planungssitzung richtig ein? Wir haben überlegt:

a) Passen Sie die Anzahl der Story-Punkte an, um nur die verbleibende Arbeit für die Fertigstellung der User Story widerzuspiegeln. Leider wird dies die Meldung des Product Backlog durcheinander bringen.

b) Schließen Sie die teilweise abgeschlossene User Story und erstellen Sie eine neue, um den Rest dieser Funktion zu implementieren, die weniger Story Points enthält. Dies wirkt sich auf unsere Fähigkeit aus, nachträglich zu sehen, was wir in diesem Sprint nicht absolviert haben, und scheint etwas zeitaufwändig zu sein.

c) Kümmere dich nicht um a oder b und rate während der Sprint-Planung weiter und sage Dinge wie "Nun, dass User Story X Story-Punkte sind, aber ich weiß, dass sie zu 95% fertig ist, also bin ich sicher, dass wir sie einpassen können."

51
Nick

Ich bin überrascht, dass es keine klare Antwort darauf zu geben scheint. Ich hatte einen Refrain von "Option D, Dummy" erwartet!

Da uns anscheinend nichts Offensichtliches gefehlt hat, haben wir angenommen, dass dies eine der Entscheidungen ist, die jedes Team für sich selbst treffen muss, basierend darauf, wie es arbeiten möchte und welche Metriken für es am wichtigsten sind.

Wir haben entschieden, dass es wichtig ist, genaue Aufzeichnungen über die von uns implementierten User Stories zu führen, da diese die Grundlage für unsere Tests, Supportdokumentationen und Versionshinweise bilden - dies schließt Option B aus.

Als nächstes stellten wir fest, dass es wichtig ist, die Sprintplanung genau durchführen zu können - das schließt Option C aus.

Wir sind daher zu dem Schluss gekommen, dass Option A für uns richtig ist. Wir werden die Story-Punkte für alle Storys, die wir teilweise in einem Sprint abgeschlossen haben, neu schätzen, damit wir sie in nachfolgenden Sprints richtig planen können. Im Laufe der Zeit wird der Product Backlog die Anzahl der von uns implementierten Story Points leicht unterschreiten. Dies wird jedoch weniger problematisch sein als alle anderen Optionen und könnte möglicherweise durch eine Änderung unserer Aufzeichnungen und Berichte behoben werden.

2
Nick

In meinem aktuellen Team machen wir c).

Die Geschwindigkeit sollte die Dinge berücksichtigen, die das Team im Sprint wirklich beendet hat. Etwas, das nicht geliefert wurde, hat für den Kunden keinen Wert, daher zählen wir keine Punkte dafür, es ist alles oder nichts.

Also verschieben wir die gesamte unvollendete Geschichte auf den nächsten Sprint und alle ihre Story-Punkte werden zur Geschwindigkeit des nächsten Sprints hinzugefügt. Die Geschwindigkeiten gleichen sich im Laufe der Zeit aus und wir nehmen einen Durchschnitt der wenigen vorherigen Sprints als Referenz, um die Schätzung zukünftiger Geschwindigkeiten zu bestimmen.

13
guillaume31

Option A ist eine allgemein empfohlene Vorgehensweise. Sie vergeben keine Punkte für die Fertigstellung der Story für den vorherigen Sprint und um die Story wieder in das Product Backlog zu verschieben, wo sie neu priorisiert wird. Sie berechnen Ihre Geschwindigkeit (und andere Metriken) basierend auf den abgeschlossenen User Stories und dem Mehrwert. Wenn Sie mit der Planung für den nächsten Sprint beginnen, nehmen Sie die Storys mit der höchsten Priorität basierend auf ihrem Wert (der die unvollendete Story enthalten kann oder nicht, wenn sich die Geschäftsprioritäten geändert haben). Wenn Sie die Geschichte schätzen, geben Sie die Arbeit an, die bereits geleistet wurde, wenn Sie die neue Anzahl von Punkten für die Geschichte berücksichtigen.

Eine alternative Option (und meine Präferenz) wäre natürlich, die ursprünglich geschätzte Anzahl von Story-Punkten zu verwenden, was ich in der Vergangenheit getan habe. Dies setzt voraus, dass Ihre Schätzung gut und fundiert war, Sie aber zu viel Arbeit für den Sprint verloren haben (z. B. - die Geschichte war tatsächlich 3 Punkte wert, aber das Problem liegt in der Tatsache, dass Sie 15 Punkte in der Geschichte verloren haben, als du hättest nur 13) runterziehen sollen. Dies ist eine potenziell gefährliche Annahme, wenn Sie nicht sicher sind, ob Sie die Schätzungen durchführen können. Sie funktioniert jedoch möglicherweise basierend auf Ihrem Team und Ihrem Prozess.

Sie erwähnen jedoch, dass dies "die Berichterstattung über das Product Backlog durcheinander bringt". Das Product Backlog sollte ohnehin dynamisch sein, wobei sich die Reihenfolge und Schätzungen der einzelnen Storys ändern, wenn mehr über die Technologie, das System, die Anforderungen und den Kunden verstanden wird. In der Regel wird aus dem Product Backlog die Anzahl der User Stories und die Gesamtzahl der Story Points gemeldet. Es ist zu erwarten, dass sich diese ändern, wenn sich Prioritäten ändern, neue Anforderungen hinzugefügt, ungültige Anforderungen entfernt und weitere Informationen gelernt werden.

11
Thomas Owens

Wenn man zu viel darüber nachdenkt, erscheint es komplizierter als es ist ... Es ist eigentlich ziemlich einfach:

Option C.

Unvollständige Storys gehen zurück in das Product Backlog, ohne dass die Punkte geändert werden. Bei der Planung des nächsten Sprints und der möglichen Maßnahmen sollte berücksichtigt werden, dass ein Großteil der Arbeit bereits erledigt ist. Wenn das Team entscheidet, dass es in den Sprint passt, geht es mit seiner ursprünglichen Anzahl von Punkten hinein. Wenn nicht, bleibt es im Rückstand. Erledigt. Die Punkte werden für den Sprint vergeben, in dem die Geschichte abgeschlossen wurde.

Wenn dies hilfreich ist, können Sie eine separate Metrik für die verbleibende Arbeit pro User Story verfolgen. Wenn die Story am Ende des Sprints nicht vollständig ist, kann die geschätzte verbleibende Arbeit in der Story notiert und berücksichtigt werden, wann Planung der Aufnahme in einen nachfolgenden Sprint. Aber ändern Sie auch dann nicht den Punktewert der Originalgeschichte.

10
Eric King

Wenn Ihr Berichterstellungstool Option A nicht genau verarbeiten kann, würde ich Option B wählen, es sei denn, Sie haben keine Hoffnung, Ihre Metriken jemals zu verwenden.

In einigen Fällen können Sie Option B ausführen UND nicht verzerren, was geschlossen bedeutet, indem Sie den Bereich der alten Aufgabe, die Sie schließen möchten, eingrenzen und nur eine neue Aufgabe für den verbleibenden Bereich erstellen. Dies macht den Verlauf semantisch sinnvoller und zeigt normalerweise Orte an, an denen Sie in Betracht gezogen haben sollten, die Aufgabe weiter aufzuschlüsseln. Manchmal ist dies nicht möglich oder logisch und Sie haben einfach eine Aufgabe, die so groß ist oder auf diese Ebene von Problemen stößt.

edit : Dies setzt voraus (wie ich glaube, dass das OP davon ausgegangen ist), dass nahezu vollständige Arbeiten nicht vorrangig niedergeschlagen wurden und dass das Erreichen der Auszahlung der vorherigen Bemühungen sie hoch genug in der Liste hält, um fortzufahren Arbeiten. Ich weiß, dass einige Geschäfte dies nicht tun, aber die meisten Orte, an denen ich gearbeitet habe, halten es für wertvoll genug, eine fast abgeschlossene Restaufgabe zu erledigen, um einfach fortzufahren, es sei denn, etwas hat sich dramatisch geändert. Die Strafe für das Ändern des Kontexts ist es oft nicht wert, die Reihenfolge zu ändern.

3
Bill

Wie schätzen wir die User Story, die wir übertragen, in der nächsten Sprint-Planungssitzung richtig ein?

Ich denke nicht, dass die Optionen A bis C gut sind, hauptsächlich, weil das, was (ich denke) in Bezug auf die Geschwindigkeit eines Teams am wichtigsten sein sollte, die durchschnittliche Geschwindigkeit und ist nicht, ob die Geschwindigkeit eines Sprints gestiegen oder gesunken ist.

Wenn eine User Story definiert ist, sollte sie Akzeptanzkriterien haben. Wenn etwas in den Akzeptanzkriterien nicht getan wird, erhält das Team einfach keinen der Punkte. Wenn die Geschichte fertig ist (d. H. Vom P.O. codiert, getestet und akzeptiert wurde), erhält das Team alle Punkte.

Dies funktioniert gut, wenn sich das Team eher auf seine Durchschnittsgeschwindigkeit als auf die Geschwindigkeit eines bestimmten Sprints konzentriert.

Wie M. Cohn in seinem Buch bevorzuge ich eher ein Alles-oder-Nichts-Szenario. Der Versuch zu schätzen, ob Sie 5 Punkte aus einer 8-Punkte-Story oder vielleicht nur 6 oder 7 Punkte erzielt haben, wird schließlich ein weiteres Ratespiel sein ... und vergessen Sie nicht, dass Sie bereits die Initiale erhalten haben Schätzung Weg weg. Es ist wahrscheinlich besser, einfach mit der einfachsten Methode zu arbeiten und alle Punkte zu erhalten, nachdem sie wirklich abgeschlossen wurde.

Zitat von M. Cohn aus seinem Buch¹ (meine Betonung):

Ich bin im Allgemeinen für eine Alles-oder-Nichts-Haltung gegenüber dem Zählen der Geschwindigkeit: Wenn eine Geschichte fertig ist (vom Produktbesitzer codiert, getestet und akzeptiert), verdient das Team alle Punkte, aber wenn etwas in der Geschichte nicht stimmt Nicht getan, sie verdienen nichts. Am Ende einer Iteration ist dies der am einfachsten zu bewertende Fall: Wenn alles erledigt ist, erhalten sie alle Punkte; Wenn etwas fehlt, bekommen sie keine Punkte. Wenn das Team in der nächsten Iteration wahrscheinlich den verbleibenden Teil der Geschichte übernimmt, funktioniert dies gut. Ihre Geschwindigkeit in der ersten Iteration ist etwas geringer als erwartet, da sie keine Anerkennung dafür erhalten haben, dass sie eine Geschichte teilweise abgeschlossen haben. In der zweiten Iteration ist ihre Geschwindigkeit jedoch höher als erwartet, da sie alle Punkte erhalten, obwohl einige Arbeiten vor Beginn der Iteration abgeschlossen wurden. Dies funktioniert gut, solange sich alle daran erinnern, dass wir hauptsächlich an der Durchschnittsgeschwindigkeit des Teams im Laufe der Zeit interessiert sind, nicht daran, ob die Geschwindigkeit in einer bestimmten Iteration nach oben oder unten gesprungen ist.

¹ Agile Schätzung und Planung , Neuschätzung teilweise abgeschlossener Geschichten, S.66

Mein Team hatte zuvor trotz einiger Einwände versucht, Teilpunkte zu vergeben, und ich denke, es hat überhaupt nicht gut funktioniert. (Wir machen das nicht mehr ... go figure) Dies ist besonders der Fall, weil Geschichten als Team geschätzt werden sollen , aber wenn Nur eine Person arbeitet daran. Für das Team wird es schwieriger sein zu wissen, wie viel eine Person ist ist tatsächlich abgeschlossen. Agile interessiert sich mehr für die Durchschnittsgeschwindigkeit eines Teams als dafür, wie "schön" ein bestimmter Sprint aussieht.

Abgesehen davon erwähnt der Autor , dass die Zuweisung von Teilpunkten in Betracht gezogen werden kann, wenn es unwahrscheinlich ist, dass das Team die verbleibende Arbeit in der nächsten Iteration in Angriff nimmt. In diesem Fall würde das Team die verbleibende Arbeit schätzen und sie in neue User Stories mit der Größe aufteilen, die sie für erforderlich halten. Wie der Autor erwähnt²:

Die kombinierten Schätzungen müssten nicht der ursprünglichen Schätzung entsprechen ...

² Ditto, S.66

Die bessere Empfehlung für das Team besteht darin, die Geschichten auf eine ausreichend kleine Größe zu reduzieren, um diese Art von Problem zu vermeiden³:

Die zwei besten Lösungen für die Zuweisung von Punkten für unvollständige Storys bestehen jedoch darin, keine unvollständigen Storys zu haben und ausreichend kleine Storys zu verwenden, damit eine teilweise Gutschrift kein Problem darstellt.

³ Ditto, S.67

Hoffe das hilft.

3
code_dredd

Wir verfolgen die Zeit, die in der Sprint-Iteration für Großschreibungszwecke aufgewendet wurde (Stunden, die für Aufgaben im Zusammenhang mit einer User Story aufgewendet wurden), und verschieben die spitze User Story, wenn das Ziel der Bestellung darin besteht, sie während des nächsten Sprints weiter zu transportieren und zu verlassen zeigt das gleiche.

Wenn das Ziel der PO darin besteht, etwas anderes an ihre Stelle zu rücken, würden wir einfach die unvollendete Geschichte in den Rückstand stellen und tun, was sie wollten. Die ursprüngliche Schätzung der Punkte zu belassen, ist meine Empfehlung, denn wenn Sie die Gewohnheit hätten, bei jedem Sprint mehr abzubeißen, als Sie kauen könnten, würden Sie Story-Punkte in einem Sprint "vervollständigen", der nicht vollständig und sauber durchgeführt wurde. getestete Gegenstände.

Wenn Sie etwas im Sprint belassen, zeigen oder versenden wollten, würde ich denken, Sie würden einen Schnittpunkt in der ursprünglichen Geschichte bestimmen, zu dem Sie den Fertigpunkt erreicht haben, und dieses kleinere Stück festlegen für Ihre Iteration. Dann könnte das Rest erneut angezeigt und in den Rückstand verschoben werden. Dies wäre eine Gelegenheit zur Neubewertung, da Sie mit Ihrem Team vereinbart haben, die Geschichte in Scheiben zu teilen.

1
user1269376

Die erste Frage lautet: Was bedeutet ein Story Point? Wenn Sie einen Story-Punkt als "Wie viel Arbeitstechnik erledigt" definieren, reicht jede Antwort aus. Wenn Sie jedoch einen Story-Punkt als "Wie viel Wert wird dem Unternehmen geliefert" definieren, ist es wichtig, erst dann eine Gutschrift zu erteilen, wenn eine Story zu 100% fertiggestellt, akzeptiert und zu 100% geliefert wurde. Das Ändern von Story-Punkten nach einem Sprint basierend auf dem, was abgeschlossen wurde, wird nur das eigentliche Problem verbergen: a) Es gab kein klares Verständnis der Story, b) Die Story war zu grob definiert, c) Der Story fehlten messbare Akzeptanzkriterien, d ) nicht tief genug Verständnis für die Aufgaben oder Abhängigkeiten, um die Geschichte zu vervollständigen, e) die Bemühungen, die Geschichte zu testen, unterschätzt, f) zu viele Punkte der Geschichte gezogen oder g) ... geben Sie hier Ihren Grund ein ...

Das Ziel von Agile ist es, flexibel und vorhersehbar zu sein. Der beste Weg, um konsistent zu sein, besteht meiner Meinung nach darin, herauszufinden, was schief gelaufen ist, ohne die ursprünglichen Schätzungen der Story zu ändern.

0
Michael Salerno