Ist es in Ordnung, die Geschichte zu Beginn des neuen Sprints neu auszurichten, um die Größe widerzuspiegeln, die wir jetzt entdeckt haben, damit unsere Geschwindigkeit genauer ist?
In seltenen Fällen arbeitet unser Team an einer Geschichte, von der wir dachten, dass wir sie in eine kleine, granulare Geschichte zerlegt hätten, aber am Ende nimmt sie den gesamten Sprint in Anspruch und wird übertragen (es kann ein Hindernis haben oder nicht). Können wir ihm einen anderen Story-Point-Wert zuweisen, um den Aufwand widerzuspiegeln, der tatsächlich für die Fertigstellung erforderlich war?
Können wir alternativ die Definition of Done aktualisieren, damit die Story im aktuellen Sprint geschlossen werden kann? Ich verstehe, dass dies nicht ideal ist und missbraucht werden könnte, damit am Ende eines Sprints alles geschlossen wird, aber ich spreche von den Geschichten, in denen Sie wissen, dass Sie WEIT über die ursprüngliche Punktschätzung hinausgegangen sind und Ihren Geschwindigkeitsprädiktor nicht wollen schief zu sein.
@Péter Török hat dir eine tolle Antwort gegeben. Ich möchte jedoch einem Aspekt seiner Aussage widersprechen: „Sie haben eine Geschichte in den Sprint aufgenommen, die noch nicht gut genug verstanden wurde, um für die Entwicklung bereit zu sein. Sie haben es versäumt, rechtzeitig einen wesentlichen Teil der Arbeit zu identifizieren.“ fertig...“ Er scheint zu erwarten, dass man die Arbeit während des Sprint Plannings vollständig vorhersehen kann und es keine Überraschungen geben sollte. Nicht wirklich!
Softwareentwicklung ist naturgemäß Teil von F&E und unvorhersehbar. Genau aus diesem Grund praktizieren wir Scrum – mit seiner Transparenz und den Inspektions-/Anpassungszyklen.
Hier ist der relevante Auszug aus dem Scrum Guide :
Das Entwicklungsteam modifiziert das Sprint Backlog während des Sprints, und das Sprint Backlog entsteht während des Sprints. Diese Entstehung erfolgt, während das Entwicklungsteam den Plan durcharbeitet und mehr über die Arbeit erfährt, die zum Erreichen des Sprint-Ziels erforderlich ist.
Wenn neue Arbeit erforderlich ist, fügt das Entwicklungsteam sie dem Sprint Backlog hinzu. Wenn Arbeit ausgeführt oder abgeschlossen wird, wird die geschätzte verbleibende Arbeit aktualisiert. Wenn Elemente des Plans als unnötig erachtet werden, werden sie entfernt.
Also meiner Meinung nach:
Wenn es häufig vorkommt, tun Sie alles, was Péter vorgeschlagen hat.
Gehen Sie mit angemessener Sorgfalt vor, um solche Überraschungen zu vermeiden. Zwei der wertvollen Praktiken, die ich sehr empfehlen kann, sind - eine Forschungsgeschichte zur Dimensionierung unbekannter Arbeit zu erstellen und einen Proof-of-Concept zu erstellen, um das Risiko bei unvorhersehbarer Arbeit zu minimieren. Wenn Sie nach all dem, was Sie tun, auf ein Problem stoßen, wie Sie in seltenen Fällen sagten, können Sie die verbleibende Arbeit zu Beginn des nächsten Sprints neu schätzen, neue Prioritäten setzen und weitermachen.
Meiner Meinung nach behandelt die Diskussion darüber, ob Sie die Geschichte neu einschätzen sollen oder nicht und wie sich dies auf Ihre Geschwindigkeit auswirkt, das Symptom anstelle der Grundursache. In der nächsten Retrospektive (oder sogar früher, in einem speziellen Meeting, wenn dies wirklich so ein wiederkehrendes Problem ist), sollten Sie sich darauf konzentrieren, warum dies auftritt und wie Sie es in Zukunft vermeiden können.
Dies deutet auf ein Problem in Ihrem Backlog-Grooming- und Sprint-Planungsprozess hin (wie Sie sagen, kommt dies nur selten vor, was mich vermuten lässt, dass Sie Backlog-Grooming dennoch im Allgemeinen praktizieren). Sie haben eine Story in den Sprint aufgenommen, die noch nicht gut genug verstanden wurde, um bereit für die Entwicklung zu sein. Sie haben es versäumt, einen wesentlichen Teil der zu erledigenden Arbeit rechtzeitig zu identifizieren, und jetzt haben Sie eine riesige Geschichte, die für den Sprint zu groß ist.
Ist es in Ordnung, die Story zu Beginn des neuen Sprints neu zu verorten, [...] oder die Definition of Done zu aktualisieren, damit die Story im aktuellen Sprint abgeschlossen werden kann?
Stories sollten auf keinen Fall einen ganzen Sprint in Anspruch nehmen. Aber wenn Sie diese Mitte des Sprints entdecken, ist meiner Meinung nach keine dieser Optionen wirklich gut. Ich denke, das Beste ist, die übergroße Geschichte auf der Grundlage Ihres frisch gewonnenen Verständnisses in kleinere neue Geschichten zu zerlegen, anstatt sie in einem Stück zu behalten. Dann können Sie jede neue Story neu einschätzen, priorisieren und entscheiden, wie viel Sie im aktuellen Sprint bewältigen können. Das ist bestenfalls immer noch chaotisch, daher möchten Sie an dieser Stelle vielleicht den Sprint in Absprache mit dem PO abbrechen und die Sprint-Planung neu starten. Es ist sicherlich eine drastische Maßnahme. Aber Ihr Sprint ist ernsthaft durcheinander, daher ist es möglicherweise besser und mehr im Sinne von Scrum, das Problem an die Oberfläche zu bringen und es im Voraus zu behandeln.
Diese Antwort konzentriert sich weniger darauf, was bei falschen Schätzungen zu tun ist, als vielmehr darauf, warum Sie historische Schätzungen nicht manipulieren sollten. Du fragst:
Ist es in Ordnung, die Geschichte zu Beginn des neuen Sprints neu auszurichten, um die Größe widerzuspiegeln, die wir jetzt entdeckt haben, damit unsere Geschwindigkeit genauer ist?
Die kurze Antwort ist "nein". Dies ist ein Missverständnis darüber, was Geschwindigkeit ist und wozu sie dient.
Das Retconning Ihrer Velocity-Metriken ist ein Projektgeruch, der darauf hindeutet, dass Velocity missbraucht wird, um Managementziele festzulegen oder das Team irgendwie zu rechtfertigen, und nicht als Planungsinstrument, das die Teamkapazität misst.
Geschwindigkeit ist keine einzelne Zahl. Idealerweise ist die Geschwindigkeit ein statistischer Bereich über einen nachlaufenden Zeitraum. Die Geschwindigkeit ist nützlich, um die Gesamtkapazität des Teams zu schätzen , ist jedoch nicht als Metrik zum Nachverfolgen abgeschlossener Arbeitsaufgaben oder des bisherigen Aufwands gedacht.
Darüber hinaus misst die Velocity implizit die Reife Ihres Schätzprozesses und sollte daher nicht nachträglich manipuliert werden. Zum Beispiel:
Wenn eine Geschichte am Ende eines Sprints unfertig bleibt, kann sie natürlich während einer zukünftigen Sprint-Planungssitzung neu geschätzt werden – hoffentlich auf genauere Weise. Das ändert nichts an den Story Points, die ihm in einem vorherigen Sprint zugewiesen wurden (irrelevant), oder an den Story Points, die es von Ihrem Projekt-Burndown (Null) abgezogen hat. Stattdessen wird es, wenn es irgendwann in der Zukunft von der Spitze des Product Backlogs abgezogen wird, einfach eine neue Schätzung für den aktuellen Sprint sein , basierend auf dem, was das Team zu diesem Zeitpunkt weiß.
Fehleinschätzungen passieren. Kleine Schwankungen in der Genauigkeit Ihrer Schätzungen sind zu erwarten und können von Ihrem Prozess absorbiert werden, wenn Sie sich nicht zu sehr verpflichten. Große Schwankungen in der Genauigkeit oder völlig ungenaue Schätzungen sind jedoch ein Prozessproblem, das vom gesamten Scrum-Team, einschließlich des Product Owners , angegangen werden sollte .
Darüber hinaus haben Sie möglicherweise kein gut formuliertes Sprintziel. Das Verwalten von Schätzungen und Backlog-Elementen ohne ein definiertes Sprint-Ziel für jeden Sprint ist eine sinnlose Übung. Tu das nicht.
Ein einzelnes Sprint-Backlog-Element sollte niemals größer als etwa 2-3 Werktage sein. Als Faustregel gilt, dass jede Aufgabe im Backlog in 1/2 Tag bis 2 Tagen „erledigt“ oder „nicht erledigt“ sein sollte, sodass Sie innerhalb von ein paar Tagen eine gute Vorstellung davon haben sollten, ob eine Story auf dem richtigen Weg ist oder nicht.
Beim täglichen Stand-up sollten Geschichten identifiziert werden, die ins Rutschen geraten. Darüber hinaus sollte Ihr Sprint-Backlog oder Kanban-Board in Arbeit befindliche Storys, die festgefahren sind, klar identifizieren, damit das Team alle Hindernisse ansprechen kann.
Scrum erwartet, wie andere Methoden, eine gewisse Pufferzeit in Ihrem Prozess, um einen reibungslosen Ablauf zu gewährleisten. Eine leicht falsch eingeschätzte Geschichte kann normalerweise ohne viel Aufhebens aufgenommen werden, aber wilde Fehlkalkulationen erfordern störendere Techniken, um damit umzugehen.
Als informelle Faustregel gilt: Wenn Ihr Sprint-Burndown um mehr als 30 % aus dem Gleichgewicht geraten ist oder wenn Sie eine einzelne Critical-Path-Story haben, die um mehr als 50 % überschätzt wird, dann lohnt es sich wahrscheinlich, die Angelegenheit zu eskalieren. Auch wenn sich das Team im aktuellen Sprint von den Fehlkalkulationen erholt, sollte es bei Ihrer nächsten Sprint-Retrospektive Wasser auf die Mühlen sein.
Eine falsch geschätzte Geschichte sollte innerhalb von 2-6 Werktagen identifiziert werden. Zuzulassen, dass eine Aufgabe um 200 % verrutscht, ohne eine Aktion oder Aufmerksamkeit im Team auszulösen, wäre einfach dumm.
An diesem Punkt sollten Sie:
Bestimmen Sie, ob die Geschichte für das Sprintziel wesentlich ist.
Wenn nicht, besprechen Sie mit dem Product Owner, es aus dem aktuellen Sprint zu ziehen. Sie können dies gemeinsam tun, solange es das Sprintziel nicht beeinträchtigt.
Schätzen Sie die Aufgabe neu ein.
Wenn die Story für das Sprint-Ziel wesentlich ist, sollten Sie sich 10-15 Minuten Zeit nehmen, um mit dem Team die Story neu zu bewerten und festzustellen, ob die Story in den aktuellen Sprint passt, mit oder ohne Änderungen am Sprint-Backlog.
Fügen Sie Kapazität hinzu, indem Sie den anderen Bereich trimmen.
Wenn Ihre Story wesentlich ist, Sie aber andere Storys haben, die es nicht sind, kann der Product Owner die nicht wesentlichen Storys ausschließen, um den Umfang einzuschränken. Darüber hinaus können Sie möglicherweise den Umfang einer Vielzahl von Sprint-Backlog-Elementen kürzen, ohne das Sprint-Ziel zu gefährden.
Fordern Sie eine vorzeitige Beendigung des aktuellen Sprints an.
Wenn die Story für das Sprint-Ziel von wesentlicher Bedeutung ist und der Umfang nicht ausreicht, um die Story innerhalb des aktuellen Sprints abzuschließen, sollten Sie den Product Owner bitten, den Sprint vorzeitig zu beenden, gefolgt von einer Sprint-Retrospektive und a zurück zur Sprint-Planung.
Jede Story, die bis zum Ende eines Sprints nicht fertig ist, wird zur Disposition durch den Product Owner an das Product Backlog zurückgegeben. Der Product Owner kann die Priorität der Story herabsetzen oder neu ausrichten, sie aus dem Backlog entfernen oder sie wieder an die Spitze des Product Backlogs setzen, um sie in den nächsten Sprint aufzunehmen.
Wenn die Story für Ihren nächsten Sprint im Rahmen bleibt, sollte sie während des Frühjahrsplanungsprozesses erneut geschätzt und zerlegt werden, genau wie jede andere Story. Hoffentlich hat das Scrum-Team es beim zweiten Mal besser im Griff, und die Schätzungen und zerlegten Aufgaben sollten zuverlässiger sein.
Wenn eine Geschichte ein drittes Mal die Runde macht, dann haben Sie ein größeres Prozessproblem als eine einzelne falsch eingeschätzte Geschichte. Repariere das.
Peter Török