Kann prognostiziert werden, wann ein Scrum-Team das Product Backlog abschließen wird?

Wenn Sie 2-3 Geschwindigkeitssprints erreichen können, wie DrewJordan empfiehlt, ist dies zweifellos der beste Weg. Allerdings sieht uns die Realität oft vor, dass das Management fragt: „Wann können Sie fertig sein“, bevor die Arbeit überhaupt begonnen hat. Wenn dies passiert, gibt es eine Methode, die ich von Agile Learning Labs gelernt habe und die gut funktioniert.

Vorbehalt: Um dies zu tun, müssen Sie eine vollständige Schätzung des Rückstands vornehmen. Wenn Sie versuchen, den Rückstand eines ganzen Jahres zu schätzen, ist dies nicht genau. Nichts kann ein Jahr plus Produkt gut abschätzen. Es ist immer noch besser als aktuelle Modelle.

Schritt 1: Wählen Sie einen angemessenen Veröffentlichungszeitraum. Wenn Sie agil arbeiten, sollten Sie höchstens alle drei Monate eine Veröffentlichung vornehmen. Wenn nicht, verlieren Sie viel von dem Wert von Agilität und werden es auch schwer haben, Agilität zu tun, wenn kein echtes Feedback eingeht. Dies wird auch direkt die Herausforderung des oben aufgeführten Vorbehalts angehen.

Schritt 2: Schätzen Sie den Rückstand. Wie im Vorbehalt erwähnt, muss dies geschehen, um ein Veröffentlichungsdatum vorhersagen zu können.

Schritt 3: Planen Sie einen theoretischen ersten Sprint. Nun, das Management ordnet Stories einem Sprint nicht zu. Das ist ehrliche teamselbstorganisierte Planung. Nehmen Sie die erste Story aus dem Backlog und das Team fragt sich: „Glauben wir, wir können das im Sprint erledigen (sie dauern zwei Wochen, oder? :)). Wiederholen Sie das dann. Machen Sie so weiter, bis das Team es tut. Sie fühlen sich nicht einmal annähernd wohl dabei, dass sie eine Geschichte zu Ende führen können. Das ist der SCHLÜSSEL. Wenn auch nur eine Person denkt, dass es nicht möglich ist, dann hören Sie auf und fügen Sie die Geschichte nicht hinzu. Es ist besser, in diesem Stadium zu unterschätzen als zu überschätzen .

Schritt 4: Projektion. Addieren Sie die Story Points der Sprintplanung. Teilen Sie nun die gesamten Story Points in einem Release auf (denken Sie daran, Ihr Ziel sind nicht mehr als etwa drei Monate). An diesem Punkt wissen Sie, wie viele Sprints Sie benötigen, um die Arbeit abzuschließen. Wenn das mehr als drei Monate Arbeit sind, ist das Release wahrscheinlich zu groß und man sollte schauen, was wirklich gebraucht wird.

Schritt 5 Bekräftigen Sie, dass dies eine PROGNOSE ist. Wenn Sie die geschätzte Zeit angeben, geben Sie diese als "Wir haben 60 % Vertrauen in diesen Zeitplan" an. Dann folgen Sie dem mit: „Nach unserem ersten Sprint sollte das auf 70 % steigen und nach unserem zweiten Sprint auf 80 %. Bei unserem dritten Sprint sollten wir 90 % Vertrauen haben, entweder was unser endgültiges Lieferdatum sein wird oder was wir getan haben werden wenn das Versanddatum auf einen bestimmten Kalenderpunkt festgelegt werden muss."

Sie werden nie mehr als 90 % Vertrauen haben, versuchen Sie es nicht. Mutter Natur und Murphy lieben es, sich mit jedem anzulegen, der sagt: „Ich habe 100 % Vertrauen“.

Sie können ein Fertigstellungsdatum, einen Datumsbereich, einen Fertigstellungssprint usw. schätzen, indem Sie die aktuelle Rückstandsgröße (in SP) durch die aktuelle Geschwindigkeit des Teams dividieren, aber ...

1. Erinnern Sie auf jeden Fall jeden, der sich Ihre Prognose ansieht, dass es sich um eine Schätzung handelt
2. Überprüfen Sie schnell, wie variabel Ihre Geschwindigkeit ist. Wie hoch ist die Geschwindigkeit der letzten 3 Iterationen des Teams? Aktuelle Iteration? Gesamtprojektdauer? Eine stark schwankende Geschwindigkeit sollte Sie veranlassen, Ihr Vertrauen in langfristige Prognoseergebnisse zu verringern.
3. Listen Sie alle Ihre Annahmen und die Methode auf, die Sie zur Ableitung der Prognose verwendet haben, bevor Sie Ihre Zahl(en) präsentieren. Stellen Sie sicher, dass Ihr Publikum die Auswirkungen der Annahmen versteht, die Sie treffen mussten.
4. Seien Sie ehrlich in Bezug auf Ihr Vertrauen in die Bereitstellung der Prognose
5. Versuchen Sie, einen Datumsbereich anstelle eines bestimmten Datums mit Zahlen für den besten, mittleren und ungünstigsten Fall anzugeben. Sie können mit Monte-Carlo-Simulationen und Tools wie Crystall Ball alle möglichen Fantasien entwickeln, wenn Sie möchten.
6. Nutzen Sie Ihre Szenarien als Chance, Risiken zu eskalieren
7. Gehen Sie KEINE langfristigen Timing-Verpflichtungen basierend auf Ihren Prognosezahlen ein. Die Prognose sollte in erster Linie als Werkzeug verwendet werden, um Risiken/Mängel zu diskutieren und hervorzuheben, die angegangen werden sollten, um die hohen Anforderungen des Kunden zu erfüllen.

Es sei daran erinnert, dass Scrum ein agiles Framework ist und es bei Agile darum geht, auf Veränderungen zu reagieren.

Es ist in Ordnung und oft nützlich, die Geschwindigkeit des Teams zu verwenden, um vorherzusagen, wann ein Rückstand abgeschlossen sein wird. Denken Sie jedoch daran, dass Sie während des Entwicklungsprozesses Veränderungen erwarten und begrüßen werden. Am Ende jedes Sprints führen Sie eine Sprint-Review durch, bei der Sie Feedback von Ihrem Product Owner und den Stakeholdern einholen. Das Team sollte hoffen, dass dieses Feedback dazu beiträgt, die Produktentwicklung näher an das zu bringen, was die Stakeholder und Benutzer wirklich wollen.

Das Ergebnis dieses iterativen Prozesses ist, dass die langfristigen Prognosen höchstwahrscheinlich nicht gleich bleiben werden. Es kann sogar erforderlich sein, die langfristigen Prognosen nach jedem Sprint zu überarbeiten.

Ja, genau das sollten Sie tun. Ich würde empfehlen, mindestens 2 Sprints und vorzugsweise 3 zu verwenden, um eine durchschnittliche Geschwindigkeit zu bestimmen.

Es ist auch wichtig, es in Bezug auf die Wahrscheinlichkeit zu formulieren: Wenn Ihre Geschwindigkeit 5 ist und es 20 Punkte gibt, dann sind Sie wahrscheinlich nach 4 Sprints fertig. Es sei denn, der Umfang ändert sich, etwas Unvorhergesehenes tritt ein, ein Risiko tritt ein usw.

Was ich tun würde, ist, für die Elemente, die nicht vollständig definiert sind, das Beste zu tun, was Sie können. Geben Sie einen Prognosebereich an (z. B. 4–6 Iterationen). Dies gibt Ihnen etwas Spielraum für Umfangsänderungen oder was auch immer kommen könnte, während Sie Ihren Stakeholdern eine Schätzung der Fertigstellung geben. Bekräftigen Sie die Idee, dass sie das Fertigstellungsdatum in beide Richtungen ändern können, basierend auf sich ändernden Anforderungen oder Umfang, wenn sie dies für nötig halten.

Wenn Sie etwas brauchen, das eher eine Wissenschaft ist, können Sie sich die PERT-Formeln ansehen . Dies kann Ihnen eine statistische Vorstellung davon geben, wann das Projekt abgeschlossen sein wird und wie wahrscheinlich diese Schätzung ist. Es ist nützlich, wenn Ihre Führungskräfte mehr Details als „4-6 Sprints“ verlangen, aber Sie können sie auch immer wieder daran erinnern, dass es sich um eine Wahrscheinlichkeit und nicht um eine gegebene Tatsache handelt.

Sie können die Geschwindigkeit Ihres Teams gegen den Rückstand auftragen und optimistische und pessimistische Veröffentlichungstermine erhalten.

Die wellenförmige schwarze Linie ist die Burn-up-Linie Ihres Teams – sie schwankt, weil die Geschwindigkeit oft schwankt. Die grüne Linie ist eine Schätzung ihres besten Abbrands/Geschwindigkeit und die rote Linie ist eine Schätzung ihres schlechtesten Abbrands/Geschwindigkeit. Wo sie sich schneiden, liefert die Linie des festen Umfangs eine Schätzung des Veröffentlichungsdatums. Ein Video, das dies erklärt, gibt es hier .

Ich habe gute Erfahrungen mit der Schätzung von Agile Monte Carlo, z. B. https://agilemontecarlo.com . Nur die durchschnittliche Geschwindigkeit zu berücksichtigen, reicht nicht aus, um das Risikoprofil des Projekts zu erhalten. Besonders für die Kommunikation mit Stakeholdern ist das 25% und 75% simulierte Lieferdatum gut zu wissen.