Ist es in Ordnung, eine Einschätzung einer Geschichte während der Ausführung zu korrigieren?

Während der Ausführung

Das ist nicht ideal, aber in der realen Welt passiert das. Und was ist die Alternative? Nicht mitteilen, dass es länger dauern könnte? Das ist keine Option. Also ja, eine Story-Schätzung kann sich während der Ausführung ändern. Wenn das oft vorkommt, könnte eine Retrospektive, warum das passiert, angebracht sein.

Wenn eine Geschichte fertig ist

Das ist ziemlich sinnlos. Eine Schätzung gilt, wenn die Geschichte noch nicht zu Ende ist. Es hat einen gewissen Wert, zu all Ihren fertigen Geschichten zurückzukehren und zu überprüfen, ob Ihre Schätzungen gut waren oder wo Sie sich verbessern müssen, aber die Schätzung selbst zu ändern ... hat zu diesem Zeitpunkt keinen Wert.

Neuschätzung in Abwesenheit des Product Owners (PO)

Nein . Der springende Punkt einer User Story ist die Kommunikation zwischen dem PO und dem Entwicklungsteam. Diese Kommunikation ohne einen Teil durchzuführen, ist einfach falsch.

Sobald ein Sprint gesperrt ist, sind die Schätzungen gesperrt, daher ist es nicht in Ordnung, eine Schätzung zu ändern, nachdem die Sprint-Planung abgeschlossen und der Sprint gesperrt ist. Es gibt ein paar Zwecke für Schätzungen:

1. Basierend auf historischen Trends – erlauben Sie der Sprint-Planung, eine gewünschte Anzahl von Punkten/Stunden zu erreichen
2. Verfolgen der Genauigkeit der Schätzer und ständiges Bereitstellen von Feedback zu ihren Schätzungen, um die Schätzungen zu verbessern

Grundsätzlich - Arbeiten Sie im Voraus an Schätzungen und ziehen Sie die Schätzer zur Rechenschaft, um sich im Laufe der Zeit zu verbessern. Oder feuern Sie sie von der Schätzung ab.

Jede Entwicklungsarbeit beinhaltet ein Entdeckungselement. Ein gutes Scrum-Team wird dafür etwas freie Kapazität einplanen, anstatt einen Sprint so voll zu packen, dass es keine Eventualitäten gibt.

Müssen Sie neu schätzen? Nun, das hängt von den Umständen ab und davon, wie viel Einfluss die Änderung wahrscheinlich haben wird.

Wenn das Team feststellt, dass einige Arbeiten länger (oder kürzer) als erwartet dauern, gibt es normalerweise zwei Möglichkeiten, um zu reagieren:

• Wenn die Auswirkungen gering sind, kann das Team einfach wie gewohnt weitermachen.
• Wenn die Auswirkungen erheblich sind, muss das Team möglicherweise neu planen und in einer Extremsituation den Sprint möglicherweise abbrechen.

In jedem Fall kann es für das Team hilfreich sein, bei der nächsten Retrospektive zu überlegen, was mit der Schätzung passiert ist. Wenn es ein konsistentes Problem mit Schätzungen gibt (z. B. Unterschätzung der Zeit, die für Abhängigkeiten benötigt wird), sollte das Team möglicherweise über Möglichkeiten nachdenken, dieses Problem anzugehen.

Wenn es während Ihres Sprints ist, möchten Sie es vielleicht ändern, wenn neue Informationen auftauchen. Idealerweise stoßen Sie es an und planen neu, wenn möglich, und ziehen eine Geschichte ein, mit der Sie sich mit der Schätzung wohler fühlen. Wenn es nicht geht: dann ja, mach es live. Bei Agilität geht es darum, was für Ihr Team und Ihren Kunden funktioniert. Wenn Sie mitten im Sprint neu schätzen und die neue Schätzung verwenden möchten: dann tun Sie es. Normalerweise interessiert sich der Kunde jedoch für die tatsächlich geleistete Arbeit, nicht für den Kostenvoranschlag. Wenn es länger dauert als erwartet: Nun, das ist das Leben, aber die Schätzung zu ändern, um dies widerzuspiegeln, bringt nicht wirklich viel.

Sie würden es wahrscheinlich nicht ändern wollen, nachdem die Geschichte abgeschlossen ist. Es ist ungefähr so, als würde man sagen: "Nun, ich schätze, diese Aufgabe wird 100 Stunden dauern". Wenn sich dann herausstellt, dass die Aufgabe 200 Stunden dauert, gehen Sie nicht zurück und sagen: „Oh, schauen Sie, wir haben geschätzt, dass die Aufgabe 200 Stunden gedauert hat … und es hat 200 Stunden gedauert! Wir sind perfekt!“. Nein, Sie haben geschätzt, dass es 100 Stunden dauern würde, und tatsächlich hat es doppelt so lange gedauert. Lernen Sie aus diesem Fehler, tun Sie nicht so, als wäre es nie passiert. Ihre Schätzungen können nie besser werden, wenn Sie sie immer zu "perfekten" Schätzungen machen.

Schnelle Antworten:

1. Wenn die Geschichte in Bearbeitung, aber nicht vollständig ist, wäre ein erneutes Verweisen unnötig. Kommunizieren Sie mögliche Verzögerungen sofort, aber die Punkte helfen da nicht weiter. Die Punkte werden verwendet, um die Kapazität zu messen, und diese Berechnung wird bereits zu Beginn des Sprints durchgeführt.

2. Ich würde ja sagen, wenn das Szenario, das ich unten beschreibe, zutrifft. Sonst hat es keinen Sinn.

3. Ich weiß nicht, ob ich vollständig verstehe, was hier vorgeschlagen wird, aber ändern Sie keine Punkte ohne das Wissen Ihres PO. Kapazität ist für diese Rolle sehr wichtig, und eine unerwartete Änderung der Punkte wird unnötige Verwirrung stiften.

Gültiges Repointing-Szenario

In unseren Engineering-Teams verwenden wir die Agile Poker Jira-App. Es ist eine fantastische Lösung für synchrone oder asynchrone Zeigesitzungen.

Ich erwähne es, weil eine der großartigen Funktionen darin besteht, Ihnen einige Beispiele von Geschichten zu zeigen, denen bestimmte Punktwerte zugewiesen wurden. Wenn Sie also glauben, dass eine Geschichte 5 Punkte haben wird, werden Ihnen einige fertige 5-Punkte-Geschichten zum Vergleich angezeigt.

Story Points nach einem Sprint unkorrigiert zu lassen, trägt in diesem Fall tatsächlich zu ungenauen Hinweisen bei, wenn man sich vorwärts bewegt. Es behindert die Fähigkeit Ihres Teams, seine Geschwindigkeit angemessen zu messen.

Als einfaches Beispiel: Wenn Sie einer Geschichte 2 Punkte geben, aber am Ende eine 5 ist, werden Sie Ihre Kapazität überschätzen, wenn Sie jemals eine ähnliche Geschichte in Ihrem bevorstehenden Sprint haben und die Punkte nicht korrigiert haben.

Wenn jemand in meinen Teams das Gefühl hat, dass die Story, an der er arbeitet, falsch eingeschätzt wurde, bringt er seinen überarbeiteten Punktvorschlag zur Genehmigung in sein Team. Es passiert ziemlich selten, und es wird immer seltener, je mehr die Teams lernen.

Wenn Sie Geschichten beim Zeigen nicht vergleichen, dann spielt es wirklich keine Rolle. Sie haben nur eine größere Fehlerquote bei Ihrer Sprintplanung, was bedeutet, dass Sie einen etwas größeren Puffer in Ihrer geschätzten Kapazität einplanen müssen.

IMO, der Zeigeprozess hat von Natur aus bereits eine große Fehlerspanne, und obwohl das in Ordnung ist, denke ich immer noch, dass alle einfachen Schritte, die wir tun können, um unsere Konsistenz zu verbessern, eine Überlegung wert sind.

Ja, es ist immer wichtig, mit dem zuständigen Teil des Teams zu kommunizieren, dass eine Aufgabe länger dauern wird.

Ich schlage vor, dass Sie einige Maßnahmen ergreifen, wenn sich eine Schätzung geändert hat. Zum Beispiel:

• Ist das Sprintziel noch erreichbar?
• Sollte sich das Team auf andere Aufgaben konzentrieren, da der aktuelle Arbeitsfluss von dieser abhing?
• Informieren Sie alle, die davon betroffen sind (nicht nur das interne Team, wenn es beispielsweise Teil einer Leistung für die Stakeholder war, sollte es eine Möglichkeit geben, diese Änderungen auch ihnen mitzuteilen.)
• Wenn es sinnvoll ist: Protokollieren Sie die Details, warum Sie die Schätzung ändern mussten, damit sie in Zukunft für bessere Schätzungen verwendet werden kann

Die Schätzung in Agile ist ein Maß für Komplexität und Unsicherheit (eine 5 liegt irgendwo zwischen 3 und 8). Das Ändern der Schätzung während des Fluges ist schädlich – Ihre historischen Schätzungen sollten denselben Unsicherheits- und Fehlerfaktor aufweisen wie aktuelle Schätzungen. Der Vergleich der geschätzten Rückstandsgröße mit der Geschwindigkeit basierend auf „Genauigkeiten“ ist Äpfel mit Birnen.

Wenn es länger dauert, sagen Sie einfach: "Es braucht mehr Zeit, Sie müssen es aufschlüsseln" oder so. Deshalb gibt es Standups. Dann seien Sie beim nächsten Mal nicht zu optimistisch.

Am Ende des Sprints sollten Sie die Schätzgenauigkeit auf Sprint-Niveau überprüfen und daraus lernen. Und Unterschätzen ist genauso schlimm wie Überschätzen.