Scrum-Überschätzung und Neuplanung

Wir sind mitten in unserem ersten Sprint und es dämmert uns etwas: Wir haben es überschätzt!

Wir hatten 114 ideale Stunden für diese 2-wöchige Iteration geplant und am Ende der ersten Woche haben wir den gesamten Sprint beendet. Was tun wir jetzt? Das "Buch" sagt, wir sollten und werden die nächsten Elemente mit hoher Priorität aus dem Rückstand erhalten. Wie fügen wir sie dem Burn-Down-Diagramm hinzu? Schreiben wir es neu, um diese Geschichten zu erklären, als ob sie von Anfang an da wären? Oder fügen Sie einfach ihre Schätzungen der y-Achse an dem Tag hinzu, an dem wir mit der Arbeit beginnen (mit einem Winkelsprung von 90 °)?

Jedes Feedback ist willkommen!

Ein Burndown-Diagramm soll unter anderem zeigen, wie im Laufe der Zeit und transparent Wert geboten wird.

Die Geschichten der neuen Benutzer waren am Anfang nicht im Sprint, daher scheint es etwas schwierig zu sein, so zu tun, als ob sie es wären. Indem Sie sie zu diesem Zeitpunkt in das Burndown-Diagramm aufnehmen, zeigen Sie genau, dass sich das aktuelle Schätzniveau noch in den vorläufigen Evolutionsphasen befindet.

Dies ist gut für Sie und Ihren Produktbesitzer. Es zeigt und wird zeigen, wie Sie mit diesem System des Projektmanagements bessere Schätzer werden können.

Sie werden von Anfang an sehen können, dass Sie zu viel geschätzt haben, dann zu wenig geschätzt haben und dann mehr, aber etwas weniger geschätzt haben ... und schließlich werden Sie die Verbesserungen bei der Schätzung im Laufe der Zeit sehen.

Ich denke, das Schätzen von User Stories ist einer der schwierigsten Teile eines Sprints. Erst wenn Ihr Team lernt, sich gemeinsam weiterzuentwickeln, werden sie dabei immer effizienter. Es ist gut, dies anhand der von Ihnen verwendeten Tools wie dem Burndown-Diagramm demonstrieren zu lassen.

Es tut nicht weh, wenn Sie den Sprint abbrechen und den nächsten Sprint unter Berücksichtigung Ihrer aktuellen Geschwindigkeit planen.

Aus dem offiziellen Scrum Guide :

Sprints können abgebrochen werden, bevor die Sprint-Zeitbox abgelaufen ist. Nur der Product Owner hat die Befugnis, den Sprint abzubrechen, obwohl er dies unter dem Einfluss der Stakeholder, des Teams oder des ScrumMaster tun kann.

Da die Sprintplanung im Rahmen einer Diskussion mit dem Produktbesitzer, dem Scrum Master und dem Team erfolgen sollte, wäre es kontraproduktiv, einfach die nächsten User Stories auszuwählen.

Wenn Sie etwas im Voraus waren, hätten Sie die Geschichte mit der nächsthöheren Priorität auswählen können, aber hier ist Ihre Situation ganz anders.

Sie können ein Abbranddiagramm hinzufügen . Sie zeigen ohne Mehrdeutigkeit, wann und wie viel neue Arbeit Sie hinzugefügt haben:

Dieses Diagramm zeigt, dass das Team in Iteration 5 20 weitere Arbeitspunkte hinzugefügt hat. Dieses Bild zeigt Iterationen, funktioniert aber genauso gut mit Tagen.

Es gibt verschiedene Techniken, um dies zu visualisieren.

Eine davon besteht darin, an dem Tag, an dem die neuen Storys hinzugefügt wurden, einen Versatz zur y-Achse (der horizontalen Achse) einzuführen, wobei das tatsächliche Burndown-Diagramm dann unter das ursprüngliche "0" -Niveau fällt.

Eine andere Möglichkeit besteht darin, so zu tun, als wären sie von Anfang an dabei (was viel einfacher ist, wenn Sie CGI-basierte Burndown-Diagramme verwenden).

Und Sie könnten sich Ihre eigenen einfallen lassen.

Das Wichtigste ist, dies zwischen Team, Scrum Master und Product Owner zu besprechen, um eine Einigung darüber zu erzielen, was Sie in dieser Situation tun möchten. Es gibt keine absolut feste Möglichkeit, etwas anderes als die Grundregeln in Scrum zu tun. Scrum soll sich im Laufe der Zeit weiterentwickeln, um den Anforderungen Ihrer Umgebung am besten zu entsprechen.

Ich möchte das Problem des OP in drei verschiedene Fragen aufteilen:

1. Sprint fortsetzen oder abbrechen?
2. Was tun in der verbleibenden Woche, wenn der Sprint fortgesetzt wird?
3. Wie plane ich den nächsten Sprint?

Burndown- und Burn-up-Diagramme, die in anderen Fragen erwähnt wurden, sind zwar nützlich, aber sekundär zu den "Was machen wir jetzt?" Des OP.

Weiter oder abbrechen : Ich bin mit Pierre hier, es ist angebracht, diesen Sprint abzubrechen und sofort mit der Planung für den nächsten zu beginnen. Sprint-Stornierung ist keine Option, wenn andere Teams vorhanden sind und Sprints synchronisiert werden müssen (die meisten Scrum-Gurus empfehlen, dass sie synchronisiert werden sollten).

Wenn der Sprint fortgesetzt wird: Begrenzen Sie die laufenden Arbeiten . Arbeiten Sie jeweils nur an einer Story und konzentrieren Sie sich auf die Fertigstellung, für die Sie weniger als eine Woche Zeit haben. Stellen Sie sicher, dass sich am Ende des Sprints keine Geschichten in einem teilweise fertigen Zustand befinden.

So planen Sie den nächsten : Hier können Sie eine relative Größenschätzung versuchen oder die Äquivalenz von Story-Point-Person-Day und den Fokusfaktor als Annäherung verwenden, wie in Henrik Knibergs Buch "Scrum and XP from the Trenches" beschrieben. Wir haben es bereits in einem anderen Thread besprochen .

Die Fertigstellung in der Hälfte der Zeit ist eine große Abweichung von den Schätzungen. Für mich würde dies ein erhebliches Risiko bedeuten, dass das, was Ihr Team tatsächlich getan hat, von den Erwartungen der Benutzer zu Beginn des Sprints abweicht. Darüber hinaus soll ein Sprint genügend Funktionen bieten, damit es jetzt Zeit für neues Feedback von der Bestellung ist.

Das Risiko, wenn Sie nur Dinge von der Oberseite des PB nehmen und weitermachen, besteht darin, dass diese Elemente oben auf dem PB veraltet sind (sowohl inhaltlich als auch vorrangig) und dass Ihr Team im letzten Sprint etwas falsch gemacht hat und Sie werden nur auf diesen Fehlern aufbauen, ohne Feedback von der Bestellung zu erhalten.

Ich würde sagen, dass die vernünftigste Vorgehensweise darin besteht, den Sprint als erledigt zu bezeichnen, das übliche Ende der Sprint-Überprüfung, das Planungsmeeting und die Retrospektive abzuhalten und mit dem nächsten Sprint zu beginnen.

In Bezug auf das Burndown-Diagramm scheint die ursprüngliche Frage den Sinn dessen zu verfehlen, wofür es ist. Es ist wirklich nur ein Werkzeug, um festzustellen, ob Sie ein Problem mit dem Fortschritt während Ihres Sprints haben. Mit dem, was beschrieben wurde, hätte das Burndown-Diagramm in dieser Situation ungefähr am 2. oder 3. Tag des Sprints ins Spiel kommen müssen, wenn es gezeigt hätte, dass das Team bei den Sprint-Aufgaben weit vor dem Zeitplan war. Dann stellen Sie die Frage "Warum?" Und stellen fest, ob Ihre Schätzungen nur weit entfernt waren oder ob die Programmierer die Aufgaben falsch interpretieren oder ob etwas in irgendeiner Weise aus dem Ruder läuft.

Aber wenn Sie die Burndown-Tabelle ignorieren und weiterfahren, als wäre nichts Seltsames los, dann sehen Sie so aus, als würden Sie sie nur als sinnloses Artefakt behandeln, das Sie produzieren, weil das "Buch" es Ihnen sagt. Meiner Meinung nach sollten Sie, wenn Sie sich entscheiden sollten, noch etwas mehr von der Oberseite des PB zu ziehen und die zweite Woche fortzufahren, einfach einen neuen Burndown für die zweite Woche starten (und dann können Sie ignorieren, wie Sie es getan haben die erste Woche).

Ich würde mich mit dem Product Owner über die zu erledigenden Arbeiten beraten und sie zum aktuellen Sprint am Tag des Einbringens der Arbeiten hinzufügen. Man kann die hinzugefügten Arbeiten in der Burndown-Tabelle verfolgen. Ich habe kein Problem mit einem Brenndiagramm, das ein bisschen wie eine Achterbahn aussieht. Dies wird trotzdem passieren, da die Scrum-Mitglieder die verbleibende Zeit für Aufgaben schätzen.