Hintergrund: Wir befinden uns in der Mitte einer Entwicklung, die für einen Kunden mit Festpreisvertrag veranschlagt wurde. Um die Schätzung zu erstellen, haben wir einen Rückstand aufgebaut, indem wir versucht haben, alle User Stories aufzulisten und ihnen dann eine Story Point-Schätzung gegeben haben.
Wir haben auch versucht, eine Gesamtzeitschätzung zu erstellen, indem wir bestimmte Storys in Aufgaben von Tagen/Stunden aufgeteilt und dann das Verhältnis von Zeit zu Story Point auf den gesamten Rückstand hochskaliert haben. Da die verwendete Technologie und das verwendete Framework dem Entwicklungsteam nicht vertraut waren (ich weiß, ich weiß ...), waren die Schätzungen eher eine Vermutung aus dem Bauch heraus. Wir haben Spikes ausgeführt, aber sie waren nicht ganz nützlich.
Wie auch immer, jetzt, da wir auf halbem Weg durch das Team sind, haben wir ein viel besseres Verständnis der verwendeten Technologien und Frameworks. Wir erwägen eine Neuschätzung (in Story Points) der verbleibenden Elemente im Backlog.
Es gibt einige widersprüchliche Meinungen im Team und einige Leute glauben, dass wir den ursprünglichen Plan aus den Augen verlieren werden und dass „man etwas gewinnt, man etwas verliert“ und sich alles ausgleichen wird. Aber gleichzeitig wäre es gut, ein genaueres Bild unserer aktuellen Fortschritte zu haben.
Meine Frage: Sollten wir die Story Points für Backlog-Items ändern, sobald die Entwicklung begonnen hat?
Überlegungen:
Unabhängig von Ihrer Methodik sollte Ihr Projektplan routinemäßig überarbeitet werden. Im traditionellen Projektmanagement bedeutet dies oft, Start- und Enddaten für Aufgaben und Meilensteine anzupassen. Bei agilen Methoden beinhaltet dies im Allgemeinen die Neuschätzung von User Stories, Durchsatzraten und Lieferterminen.
Wie auch immer, jetzt, da wir auf halbem Weg durch das Team sind, haben wir ein viel besseres Verständnis der verwendeten Technologien und Frameworks. Wir erwägen eine Neuschätzung (in Story Points) der verbleibenden Elemente im Backlog.
Herzliche Glückwünsche! Sie haben gerade den Wert der iterativen Schätzung in agilen Methoden entdeckt.
Mit fortschreitendem Projektverlauf verengt sich der Unsicherheitskegel normalerweise und die Genauigkeit Ihres Teams bei der Schätzung der Arbeit verbessert sich im Allgemeinen. Wikipedia sagt:
Im Projektmanagement beschreibt der Cone of Uncertainty die Entwicklung der Unsicherheit während eines Projekts. Zu Beginn eines Projekts ist vergleichsweise wenig über das Produkt oder die Arbeitsergebnisse bekannt, sodass Schätzungen mit großen Unsicherheiten behaftet sind. Je mehr Forschung und Entwicklung durchgeführt wird, desto mehr Informationen werden über das Projekt gewonnen, und die Unsicherheit nimmt dann tendenziell ab und erreicht 0 %, wenn alle Restrisiken beendet oder übertragen wurden.
In Scrum werden einzelne Stories in jedem Sprint neu geschätzt, wenn sie aus dem Product Backlog herausgelöst werden. Während des Backlog Grooming wird auch ein gewisses Maß an Neuschätzung durchgeführt, einschließlich der Schätzung neuer Epics oder Stories, wenn sie im Laufe der Zeit zum Product Backlog hinzugefügt werden. Das Wertversprechen der Neuschätzung des gesamten verbleibenden Product Backlogs ist jedoch etwas anders.
Wir befinden uns in der Mitte einer Entwicklung, die für einen Kunden mit einem Festpreisvertrag veranschlagt wurde.
Erstens ist ein Kostenvoranschlag keine Verpflichtung. Während Sie möglicherweise vereinbart haben, eine feste Menge an Arbeit zu einem Festpreis zu liefern, ist das Lieferdatum eines Festpreisvertrags in der Regel in mindestens einer der folgenden Dimensionen flexibel, sofern Ihr Vertrag nichts anderes vorsieht:
Der Wert der Neuschätzung des verbleibenden Product Backlogs in diesem Szenario besteht darin, dass Sie jetzt genauere Schätzungen haben von:
Dies schafft Transparenz für das Projekt und gibt den Beteiligten die Möglichkeit, das Projekt bei Bedarf anzupassen. Beispielsweise kann eine genauere Projektschätzung es ihnen ermöglichen, neue Kosten-Nutzen-Vergleiche über bestimmte Funktionen anzustellen oder Geld zu sparen, indem sie ein Projekt beenden, das bereits einen ausreichenden Geschäftswert für die Auslieferung in unveränderter Form erbracht hat.
Wenn Sie das Pech haben, ein Projekt zu verwalten, das gleichzeitig in allen drei Dimensionen (z. B. Kosten, Umfang und Geschwindigkeit) eingeschränkt ist, dann besteht der einzige wirkliche Wert bei der Neuschätzung des Projekts darin, festzustellen, ob es scheitern wird, wie es scheitern kann, oder was neu verhandelt werden muss, um den Ertragswert für das Projekt zu retten.
Wenn dies Ihre Situation ist, besteht das Ziel der Neuschätzung darin, die Transparenz und Kommunikation mit den Interessengruppen zu verbessern. Daher hat die Neuschätzung sowohl für das Team als auch für den Kunden eindeutig einen Wert.
Ich hatte mit meinem Team das gleiche Problem. Was ich gelernt habe ist, wenn Sie mit aktuellen Schätzungen nicht zufrieden sind, machen Sie es, aber verschwenden Sie keine Zeit damit, In-Sprint- oder vergangene Geschichten neu zu schätzen. Konzentrieren Sie sich auf die Durchsetzung der Grundregeln für die Verwendung von Punkten für neue Punkte:
Ziehen Sie auch in Betracht, regelmäßige Backlog-Refinement -Meetings zu verwenden, es ist kein Problem, Stories neu zu schätzen, ich würde sogar vorschlagen, dies sehr oft zu tun, um Ihren Backlog mit der Realität in Einklang zu bringen.
sollten wir die Story Points für Backlog-Items ändern, sobald die Entwicklung im Gange ist
wenn dies dem Team und den Geschäftsleuten helfen wird, die Situation besser zu verstehen - absolut!
Sie sollten auch erwägen, diesen Sprint abzubrechen und einen neuen zu starten (wenn die Änderung groß genug ist).