Ist es in Ordnung, Schätzungen während einer Iteration zu ändern?


14

Wir haben damit begonnen, Agile / Scrum in einem Team von 4 Entwicklern einzusetzen. Wir haben unsere Story-Schätzungen durchgeführt und die Storys im Product Backlog geordnet.

Wir begannen mit der punktbasierten Schätzung der Komplexität von 1 bis 5 anstelle der üblichen 1,2,3,5,8,13 .... und so weiter

Nachdem wir an ein paar Geschichten gearbeitet hatten, hatten wir das Gefühl, dass einige der Geschichten, die auf 4 geschätzt wurden, nur 2 sein sollten, während die anderen, die auf 2 geschätzt wurden, viel komplexer sind und mit 5 hätten geschätzt werden müssen kennt:

  • Ist es in Ordnung, unsere Geschichtsschätzungen mitten in der Iteration zu ändern?
  • Ist es in Ordnung, die aktuellen Schätzpunkte von 1 bis 5 anstelle der üblichen 1,2,3,5,8,13 zu verwenden ... und so weiter

Obwohl ich persönlich der Meinung bin, dass dies in beiden Fällen nicht der Fall sein sollte, muss ich mich selbst unterstützen, da mein eigenes Verständnis nicht sehr klar ist. (Gutes Ref-Material wäre allerdings gut!)


4
Fragen Sie sich: Was bringt es, wenn Sie sich die Zeit nehmen, um den Sprint neu einzuschätzen? Was nützt es, mehr Zeit damit zu verbringen, über feinkörnige 3 vs. 4 vs. 5 zu streiten, als über grobe 3 vs. 5?
Hugo

Antworten:


13

Ist es in Ordnung, unsere Geschichtsschätzungen mitten in der Iteration zu ändern?

Absolut nicht. Wir erwarten, dass das passiert. Und wir erwarten, dass sich die Fehler im Laufe der Zeit ausgleichen. Wir passen Schätzungen nur dann wirklich an, wenn klar ist, dass eine bestimmte Kategorie (z. B. neue Webseiten) immer komplexer sein wird, als wir gedacht hatten, als wir sie alle geschätzt haben.

Da eine epische Geschichte in kleinere Geschichten zerlegt wird (was lange vor dem Sprint geschehen sollte), scheinen wir die ursprüngliche Schätzung möglicherweise anzupassen, aber ich würde es als Verfeinerung bezeichnen, anstatt sie neu zu schätzen. Das liegt daran, dass wir zu diesem Zeitpunkt eine klarere Sicht haben.

Mike Cohns Agile Estimating and Planning ist ein gutes Buch zu diesem Thema. Ich würde davor warnen, es (oder ein "Agiles" Buch) als Bibel zu verwenden, aber es ist ein guter Ausgangspunkt, um Ihren Prozess zu verfeinern.

Er spricht über die Art und Weise, wie sich falsche Schätzungen als "Magie" ausgleichen, betont jedoch, dass er gesehen hat, wie es immer und immer wieder funktioniert.

Ist es in Ordnung, die aktuellen Schätzpunkte von 1 bis 5 anstelle der üblichen 1,2,3,5,8,13 zu verwenden ... und so weiter

Die Verwendung der Fibonacci-Punktserienschätzung ist eine Annahme, dass unsere Schätzung umso ungenauer ist, je größer eine Geschichte ist (siehe meinen früheren Kommentar zu Epics).

Aber wenn es bei Ihnen nicht funktioniert, besonders wenn Sie alle Ihre Jobs klein halten, dann verwenden Sie es nicht. Es ist eine Richtlinie, keine Regel.

T-Shirt-Größen (SML XL XXL) sind ebenfalls beliebt und unterscheiden sich im Wesentlichen nicht von (1 2 3 4 5).


+1: Besprechen Sie dies während Ihrer Retrospektive. Schätzen Sie neu, wann Sie zu Beginn des nächsten Frühlings Prioritäten setzen. Deshalb hast du Sprints. Kein Verwaltungsaufwand während des Sprints - nur Code erstellen.
S.Lott

Über die Verwendung von Fabonacci-Serien, Angenommen, Sie wissen, dass eine Geschichte fast 3 Tage dauern wird und die Nr. Die Aufgaben für die Story lauten A, B, C. Sie glauben auch, dass es nicht sehr komplex ist, aber jede dieser Aufgaben wird jeweils 1 Tag dauern. Welche Schätzung würden Sie der Geschichte geben?
Tim und Struppi

@tintin: Der Grund für die Verwendung von Punkten ist, Dinge wie "Sie wissen, dass eine Geschichte fast 3 Tage dauern wird" nicht auszusprechen. Die Punkte sind relativ willkürlich, jeder Job basiert auf Komplexität im Vergleich zu anderen Jobs (offensichtlich sollten Sie falsch eingeschätzte Jobs nicht als Basis verwenden). Sie vermeiden jedoch die fehlenden Zahlen, um die Unsicherheit zu berücksichtigen. Wenn also Job B doppelt so komplex ist wie Job A und Job A mit 2 Punkten markiert wurde, markieren Sie Job B mit 5 Punkten.
pdr

+1 für: je größer eine Geschichte ist,
desto

1

Ist es in Ordnung, unsere Geschichtsschätzungen mitten in der Iteration zu ändern?

Absolut ja - ob es die aktuelle oder zukünftige Frühjahrsplanung beeinflusst. Das Agile besteht darin, Ihre Handlungen auf Informationen zu stützen, die so aktuell und korrekt wie möglich sind.

Wenn sich herausstellt, dass eine Schätzung so falsch ist, dass der aktuelle Sprint nicht in seiner Timebox beendet werden kann, müssen Sie die überarbeitete Schätzung anwenden, und Sie möchten sie wahrscheinlich ändern. Wenn Sie neue Schätzungen auf alten basieren (und diese tatsächlich betrachten, anstatt sich auf Erinnerung / Erfahrung zu verlassen), müssen diese korrekt sein.

Auf der anderen Seite ist es nicht wirklich Wert per se in einer Schätzung korrekt. Verschwenden Sie keine Zeit damit, bedeutungslose Statistiken zu verschönern.


In unserem Fall war die anfängliche Schätzung groß, und der Aufwand dafür ist weitaus geringer. Es ist also nicht so, dass unser aktueller Sprint nicht rechtzeitig beendet ist, aber wir haben zusätzliche Zeit. Der Manager schlägt daher vor, die Schätzung zu senken.
Tim und Struppi

@Michael, diese Antwort mag für einige agile Prozesse zutreffen, aber die Frage bezieht sich auf Scrum. In Scrum wird nicht empfohlen, die Story-Punkte nach der Sprint-Planung zu ändern, da die Geschwindigkeitsmetrik des Teams beeinträchtigt werden könnte.
GuyR

Fehlgeschlagene Schätzungen haben den Vorteil, dass Sie sie verwenden können, um zukünftige Schätzungen entsprechend anzupassen. Wenn Sie zu lange schätzen, ist dies ebenso ein Fehler wie eine zu kurze Schätzung, da die Ressourcen nicht ausgelastet sind. Der Wert korrekter Schätzungen besteht darin, dass Sie wissen, dass Sie wahrscheinlich Ihre Veröffentlichungsziele erreichen, und Ihr Team voll ausgelastet ist. Daher stützen Sie zukünftige Schätzungen immer auf Ihre bisherigen Erfahrungen und passen diese an, je nachdem, was Sie auf dem Weg über Ihre Schätzungen erfahren.
S.Robins,
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.