Wir verwenden Scrum und stellen gelegentlich fest, dass wir eine User Story in dem Sprint, in dem sie geplant war, nicht ganz fertigstellen können. Im wahren Scrum-Stil liefern wir die Software trotzdem aus und erwägen, die User Story in der nächsten Sprint-Planungssitzung in den nächsten Sprint aufzunehmen. Wie schätzen wir dies in der nächsten Sprint-Planungssitzung richtig ein, da die User Story, die wir übertragen, teilweise vollständig ist? Wir haben überlegt:
a) Passen Sie die Anzahl der Story-Punkte an, um nur die Arbeit wiederzugeben, die zum Abschließen der User Story verbleibt. Leider wird dies die Meldung des Product Backlogs durcheinander bringen.
b) Schließen Sie die unvollständige User Story und eröffnen Sie eine neue, um den Rest der Funktion zu implementieren, die weniger Story Points hat. Dies wirkt sich auf unsere Fähigkeit aus, nachträglich zu sehen, was wir in diesem Sprint nicht absolviert haben, und scheint etwas zeitaufwendig zu sein.
c) Kümmern Sie sich nicht um a oder b und raten Sie während der Sprint-Planung weiter: "Gut, dass die User Story aus X Story-Punkten besteht, aber ich weiß, dass sie zu 95% fertig ist. Ich bin mir also sicher, dass wir sie einfügen können."
quelle
Antworten:
In meinem jetzigen 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 ganze unvollendete Geschichte auf den nächsten Sprint und alle ihre Geschichtenpunkte werden zur Geschwindigkeit des nächsten Sprints addiert. Die Geschwindigkeiten gleichen sich mit der Zeit aus, und wir verwenden einen Durchschnitt der wenigen vorherigen Sprints als Referenz, um die geschätzten zukünftigen Geschwindigkeiten zu bestimmen.
quelle
Option A ist eine allgemein empfohlene Vorgehensweise. Sie vergeben keine Punkte für die Vervollständigung der Story für den vorherigen Sprint und um die Story zurück in den 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 (die möglicherweise die unvollendete Story enthalten, wenn sich die Geschäftsprioritäten geändert haben). Berücksichtigen Sie bei der Schätzung der Geschichte die bereits geleistete Arbeit, wenn Sie die neue Punktzahl 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 lässt vermuten, dass Ihre Schätzung gut und fundiert war, Sie aber zu viel Arbeit für den Sprint geleistet haben (z. B. - die Story war tatsächlich 3 Punkte wert, aber das Problem liegt in der Tatsache, dass Sie 15 Story-Punkte geleistet haben, als du hättest nur runterziehen sollen 13). Dies ist eine potenziell gefährliche Annahme, wenn Sie nicht sicher sind, ob Sie die Schätzungen durchführen können, sie jedoch möglicherweise auf der Grundlage Ihres Teams und Ihres Prozesses funktioniert.
Sie erwähnen jedoch, dass dies "das Reporting des Product Backlogs durcheinander bringt". Das Product Backlog sollte ohnehin dynamisch sein, wobei sich die Reihenfolge und Schätzungen der einzelnen Storys ändern, je mehr über die Technologie, das System, die Anforderungen und den Kunden bekannt ist. In der Regel werden aus dem Product Backlog die Anzahl der User Stories und die Gesamtanzahl der Story Points gemeldet. Es ist zu erwarten, dass sich diese ändern, wenn sich Prioritäten ändern, neue Anforderungen hinzugefügt werden, ungültige Anforderungen entfernt werden und weitere Informationen gelernt werden.
quelle
Wenn man zu viel darüber nachdenkt, erscheint es komplizierter als es ist ... Eigentlich ist es ziemlich einfach:
Option C
Unvollständige Storys werden ohne Änderung der Punkte wieder in das Product Backlog aufgenommen. Bei der Planung des nächsten Sprints und was getan werden kann, sollte die Diskussion die Tatsache berücksichtigen, dass ein Großteil der Arbeit bereits erledigt ist. Wenn das Team entscheidet, dass es in den Sprint passt, wird es mit der ursprünglichen Punktzahl eingesetzt. Wenn nicht, bleibt es im Rückstand. Getan. Die Punkte werden für den Sprint vergeben, in dem die Geschichte abgeschlossen wurde.
Wenn dies hilft, können Sie eine separate Kennzahl für "verbleibende Arbeit" pro User Story nachverfolgen. Wenn die Story am Ende des Sprints nicht vollständig ist, kann die geschätzte verbleibende Arbeit auf der Story notiert und berücksichtigt werden, wann Planung seiner Aufnahme in einen nachfolgenden Sprint. Aber ändern Sie auch dann nicht den Punktewert der Originalgeschichte.
quelle
Wenn Ihr Berichterstellungstool Option A nicht genau verarbeiten kann, würde ich Option B wählen, es sei denn, Sie haben keine Hoffnung, jemals Ihre Messdaten 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, einschränken und nur für den verbleibenden Bereich eine neue Aufgabe erstellen. Dies macht die Historie semantisch sinnvoller und zeigt normalerweise Stellen an, an denen Sie überlegt haben sollten, die Aufgabe weiter aufzuschlüsseln. Manchmal ist dies nicht möglich oder logisch und Sie haben einfach eine Aufgabe, die so umfangreich ist oder auf diese Ebene von Problemen stößt.
edit: Dies setzt voraus (wie ich glaube, dass das OP davon ausgegangen ist), dass die fast vollständige Arbeit nicht vorrangig niedergeschlagen wurde und dass es hoch genug in der Liste bleibt, um mit der Arbeit fortzufahren, wenn man die Auszahlung der vorherigen Anstrengung erreicht. 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 nahezu vollständige Restaufgabe abzuschließen, 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.
quelle
Ich denke nicht, dass die Optionen A bis C gut sind, vor allem, weil (meiner Meinung nach) die Durchschnittsgeschwindigkeit eines Teams am wichtigsten ist und nicht, ob die Geschwindigkeit eines bestimmten Sprints nach oben oder unten ging.
Wenn eine User Story definiert ist, sollte sie Akzeptanzkriterien haben. Wenn die Akzeptanzkriterien nicht eingehalten werden, erhält das Team einfach keine Punkte. Wenn die Geschichte fertig ist (dh codiert, getestet und von der PO akzeptiert), erhält das Team alle Punkte.
Dies funktioniert gut, wenn sich das Team auf die Durchschnittsgeschwindigkeit und nicht auf die Geschwindigkeit eines bestimmten Sprints konzentriert.
Wie M. Cohn in seinem Buch neige ich dazu, ein Alles-oder-Nichts-Szenario zu bevorzugen. Schließlich ist der Versuch, abzuschätzen, ob Sie 5 Punkte aus einer 8-Punkte-Geschichte oder nur 6 oder 7 Punkte erreicht haben, nur ein weiteres Ratespiel ... und vergessen Sie nicht, dass Sie bereits die Initiale haben abschätzen weg. Es ist wahrscheinlich besser, einfach mit der einfachsten Methode zu arbeiten und alle Punkte zu sammeln, nachdem sie wirklich abgeschlossen wurden.
Zitat von M. Cohn aus seinem Buch¹ (meine Betonung):
¹ Agile Schätzung und Planung , Neuschätzung teilweise abgeschlossener Geschichten, S.66
Mein Team hatte zuvor trotz einiger Einwände versucht, Teilpunkte zuzuweisen, und ich denke, es hat überhaupt nicht gut funktioniert. (Wir tun es nicht mehr ... go figure) Dies ist insbesondere dann der Fall , weil Geschichten sollen , erhalten geschätzt als Team , wenn doch nur eine Person daran arbeitet, wird es schwieriger sein , für das Team zu wissen, wie viel eine Person tatsächlich abgeschlossen hat. Agile interessiert sich mehr für die Durchschnittsgeschwindigkeit eines Teams als dafür, wie "schön" ein bestimmter Sprint aussieht.
That being said, der Autor hat erwähnt , dass Teil Punkte Zuordnung in Betracht gezogen werden kann , wenn das Team unwahrscheinlich ist , die verbleibende Arbeit in der nächsten Iteration zu bewältigen. In diesem Fall schätzt das Team die verbleibende Arbeit und unterteilt sie in neue User Storys mit der Größe, die es für erforderlich hält. Wie der Autor erwähnt²:
² Dito, S.66
Die bessere Empfehlung für das Team ist, die Storys so klein zu halten, dass ein solches Problem vermieden wird³:
³ Dito, S.67
Hoffe das hilft.
quelle
Ich bin überrascht, dass es keine eindeutige Antwort darauf zu geben scheint. Ich hatte einen Refrain von "Option D, Dummy" erwartet!
Da uns anscheinend nichts Offensichtliches entgangen ist, stellten wir fest, 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 sie am wichtigsten sind.
Wir haben uns entschlossen, genaue Aufzeichnungen über die von uns implementierten User Stories zu führen, da diese die Grundlage für unsere Tests, Support-Dokumentationen und Release Notes bilden - das schließt Option B aus.
Als nächstes haben wir herausgefunden, dass es wichtig ist, die Sprintplanung genau durchzuführen - 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 Produktbestand die Anzahl der von uns implementierten Story Points geringfügig unterschreiten. Dies ist jedoch weniger problematisch als alle anderen Optionen und könnte möglicherweise durch eine Änderung unserer Protokollierung und Berichterstellung behoben werden.
quelle
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 ausgewählte User Story, wenn das Ziel der PO darin besteht, sie während des nächsten Sprints weiter zu nutzen und zu verlassen zeigt das gleiche.
Wenn es das Ziel der PO ist, etwas anderes an seine Stelle zu rücken, würden wir die unvollendete Geschichte einfach in den Rückstand setzen und tun, was sie wollten. Die ursprüngliche Schätzung der Punkte zu belassen, ist meine Empfehlung, denn wenn Sie die Angewohnheit 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 erledigt und sauber war. geprüfte Artikel.
Wenn Sie etwas im Sprint belassen wollten oder etwas ausliefern mussten, würden Sie wahrscheinlich einen Schnittpunkt innerhalb der ursprünglichen Geschichte bestimmen, zu dem Sie den Endpunkt erreicht haben, und das kleinere Stück festlegen für Ihre Iteration. Dann konnte der Rest erneut verwiesen und in den Rückstand geworfen werden. Dies wäre eine Gelegenheit, eine Neueinschätzung vorzunehmen, da Sie sich mit Ihrem Team darauf geeinigt haben, die Geschichte in Scheiben zu teilen.
quelle
Die erste Frage lautet: Was bedeutet ein Story Point? Wenn Sie einen Story Point als "Wie viel Arbeit wird ausgeführt" definieren, ist jede Antwort ausreichend. Wenn Sie jedoch einen Story-Punkt als "Wie viel Wert wird dem Unternehmen geliefert?" Definieren, ist es wichtig, keine Gutschrift zu erteilen, bis eine Story zu 100% fertiggestellt, akzeptiert und zu 100% geliefert wurde. Das Ändern der Story-Punkte nach einem Sprint auf der Grundlage dessen, 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 ) die Aufgaben oder Abhängigkeiten nicht tief genug verstehen, um die Geschichte zu vervollständigen, e) den Versuch, die Geschichte zu testen, unterschätzt haben, f) zu viele Geschichtenpunkte aufgeschrieben haben, oder g) ... hier den Grund eintragen ...
Das Ziel von Agile ist es, flexibel und vorhersehbar zu sein. Meiner Meinung nach ist der beste Weg, um konsequent zu bleiben, herauszufinden, was schief gelaufen ist, ohne die ursprünglichen Schätzungen der Story zu ändern.
quelle