Warum stimmt unsere Sprint-Planung nicht mit unserem ursprünglichen Release-Plan überein?

Sobald Sie sagten "Das Team hat geschätzte Stunden angegeben", habe ich hier ein Problem erkannt. Wenn Sie Release-Management auf hohem Niveau betreiben, müssen Sie sich darüber im Klaren sein, dass selbst das Anwenden von Story Points auf Epics eine wirklich ungenaue Aufgabe ist und nur in groben Zügen verwendet werden kann. Der Versuch, die Stunden tatsächlich zu schätzen, ist zum Scheitern verurteilt.

Wie einige andere gesagt haben, ja, es hört sich so an, als ob Ihr Team beim Schätzen nicht besonders gut war und dass es die Schätzungen viele Male geändert hat. Als Produktmanager denke ich jedoch, dass eines der großartigen Dinge an Agile ist, dass es versucht, die Schmerzpunkte zu lindern, die durch den Versuch entstehen, weit im Voraus zu planen.

Ich habe Release-Planungsmeetings mit meinem Team durchgeführt, sowohl auf der hohen Ebene der Aufteilung des großen Projekts in Epen und deren Schätzung (20, 40, 60, 80, 100 waren die Optionen) als auch auf der unteren Ebene in den wenigen aufeinanderfolgenden Monaten bis zur Freigabe der Nutzung von Story Points und Team Velocity. Agile lehrt uns, dass Sie nie alle kleinen Dinge wissen werden, die für ein Release getan werden müssen, bis Sie nahe dran sind – das ist die Natur von Software und der Arbeit mit Menschen. Einige Komplexitäten werden übersehen, Sie stellen möglicherweise einen Monat vor dem Start fest, dass die Funktion, von der Sie dachten, dass sie perfekt gestaltet ist, wirklich einige zusätzliche Kriterien benötigt, usw. Ich empfehle, wenn Sie die Planung auf hoher Ebene mehr als 2 Monate im Voraus durchführen, kommunizieren Sie nur mit den Kunden in welchem ​​Quartal Sie mit der Veröffentlichung rechnen,

Das kann an mehreren Dingen liegen:

• Die Anforderungen. Je weniger detailliert und klar Ihre Anforderungen sind, desto mehr können Sie mit erheblichen Fehlern in Ihren Schätzungen rechnen. Müll rein ergibt Müll raus
• Der Schätzprozess. Wenn Ihre Anforderungen gut genug sind, um vernünftige Schätzungen zu liefern, können die Schätzungen dennoch abweichen, wenn der Prozess nicht streng genug ist oder wenn nicht genügend Gedanken in die Schätzungen gesteckt werden.
• Die Unternehmenskultur. Ich habe gesehen, wie Kostenvoranschläge gefälscht wurden, um einem Kunden das zu sagen, was er hören möchte, weil die Unternehmenskultur eine war von „Erhalte den Vertrag und mache dir Gedanken darüber, wie du später liefern kannst“. Abhängig von Ihrer Organisation kann es auch Konsequenzen für das Aussprechen unangenehmer Wahrheiten geben.
• Der Schätzer. Im Allgemeinen sind die Menschen optimistisch und geben Ihnen entsprechende Schätzungen. Dies wird noch schlimmer, wenn Sie Schätzungen von jemandem erhalten, der die Arbeit nicht wirklich erledigt. Wenn Sie einen Kostenvoranschlag erhalten, sollten Sie ihn idealerweise hinterfragen und dem Schätzer die Möglichkeit geben, um mehr Zeit zu bitten.
• Die Erwartungen. Wenn Sie ursprünglich grobe Schätzungen erstellt haben, ist davon auszugehen, dass zwischen diesen Schätzungen und den Ergebnissen einer detaillierteren Planung möglicherweise erhebliche Abweichungen bestehen. Als PM sollten Sie die Erwartungen der Interessengruppen steuern, indem Sie ihnen eine Reihe von Lieferterminen vorgeben, die sich mit zunehmender Detailplanung verengen. Wenn Sie beispielsweise eine grobe Schätzung haben, dass die Arbeit 20 Wochen dauern wird, können Sie dem Kunden präsentieren, dass die Arbeit 18 bis 35 Wochen dauern wird. Wenn die Anforderungen konkretisiert werden und Sie mehr darüber wissen, was geliefert werden muss und wie, wird die Schätzung vielleicht auf 25 Wochen revidiert, aber Sie präsentieren sie mit 24 bis 30 Wochen.

Aufgrund der von Ihnen gegebenen Beschreibung vermute ich, dass Sie in Bezug auf die Genauigkeit von einer Schätzung auf hoher Ebene zu viel erwartet haben. Die einzige Lösung dafür besteht darin, zum Team zurückzukehren und es zu bitten, die verbleibende Arbeit neu zu schätzen, wobei Sie eine Schätzung für den wahrscheinlichsten und den ungünstigsten Fall erhalten. Präsentieren Sie diese Ihrem Kunden und wenn sie damit zufrieden sind, klicken Sie auf die Schaltfläche „Projekt zurücksetzen“ und fahren Sie fort.

TL;DR

Die Veröffentlichungsplanung ist ein geschätztes Managementziel, das im Allgemeinen auf Aufwandsschätzungen großer Themen oder Epics basiert. Sprint Planning ist eine Teamverpflichtung, die auf User Stories in Iterationsgröße basiert. Sie erfüllen unterschiedliche Funktionen, aber der Schlüssel ist, sich daran zu erinnern, dass Schätzungen keine Garantien sind.

Planänderungen bedeuten nicht zwangsläufig, dass Ihre Schätzungen grundsätzlich falsch sind. Ihr Ziel sollte es sein, die Genauigkeit Ihrer Schätzungen zu verbessern, und nicht, willkürliche Planungsziele zu erreichen. Die Verbesserung der Genauigkeit Ihrer Schätzungen sollte jedoch Abweichungen in Ihrer auf Schätzungen basierenden Planung auf ein akzeptables Niveau reduzieren.

Release-Planung in der iterativen Entwicklung

Bei der Release-Planung geht es in erster Linie darum, Meilensteine ​​und voraussichtliche Liefertermine zu definieren. Der Unsicherheitskegel ist zu Beginn eines neuen Projekts immer am größten, und daher sollte die Genauigkeit des anfänglichen Release-Plans in einem Bereich mit einem definierten Konfidenzintervall liegen.

Da es sich bei Scrum um einen iterativen Entwicklungsprozess handelt, sollte die Release-Planung bei jeder Iteration überprüft werden. Basierend auf dem, was zu Beginn jeder Iteration derzeit bekannt ist, kann das Product Backlog geändert werden, um den Umfang zu reduzieren oder die Prioritäten zu ändern, um feste Veröffentlichungstermine zu erreichen, oder die Veröffentlichungstermine können verschoben werden, um den tatsächlichen Fortschritt des Teams in Bezug auf das Geplante genauer widerzuspiegeln Freisetzung.

Freisetzbare Inkremente

Es gibt eine Reihe von Kernideen hinter der agilen Entwicklung, aber eines der Kernkonzepte ist die Idee von Iterationen, die „potenziell freisetzbare Inkremente“ produzieren. Mit anderen Worten, während ein bestimmter Sprint möglicherweise nicht den vollständigen Satz von Features enthält, die für ein bestimmtes Release-Ziel geplant sind, sollte jeder Sprint ein funktionierendes, funktionales und (idealerweise) für den Benutzer sichtbares Feature hervorbringen, das veröffentlicht werden könnte .

Anders ausgedrückt, jeder Sprint sollte zu einem Produkt führen, das einen gewissen Ertragswert generiert hat. Auch wenn das Produkt möglicherweise nicht vollständig ist, ist es dennoch funktionsfähig und möglicherweise am Ende jedes Sprints auslieferbar. Dies gibt den Beteiligten die Möglichkeit , den verdienten Wert am Ende jeder Iteration in den Marktwert umzuwandeln, obwohl sie dies sicherlich nicht tun müssen.

Kontinuierliche Neuschätzung

Der Schlüssel zu erfolgreichen Scrum-Implementierungen liegt in der kontinuierlichen Neubewertung. Diese Neuschätzung umfasst natürlich Epics, Themes und User Stories, aber auch die Neuschätzung von Projektzeitplänen und des Umfangs von Zielmeilensteinen.

Abweichungen von anfänglichen Schätzungen sind zu erwarten und werden durch den in Scrum integrierten Inspect-and-Adapt-Prozess behandelt. Wenn Sie jedoch feststellen, dass Ihre Schätzungen im Laufe der Zeit nicht genauer werden, müssen Sie Folgendes tun:

1. Bewerten Sie Ihren Schätzprozess neu, um zu sehen, wo Sie sich verbessern könnten, und
2. Stellen Sie fest, ob Ihre ursprüngliche Planungs-Baseline auf fehlerhaften Annahmen basierte.

Auch das Management muss Veränderungen annehmen

„Veränderung annehmen“ ist nicht die alleinige Domäne des Entwicklungsteams in Scrum. Es liegt auch in der Verantwortung des Product Owners und der Stakeholder, alle notwendigen Änderungen an Umfang, Zeitplan, Ressourcen, Marktkräften und anderen Realitäten vorzunehmen, die erforderlich sind, um sicherzustellen, dass das Projekt entweder erfolgreich ist oder frühzeitig scheitert.

Das Festhalten an einem Plan, der vor Monaten oder Jahren erstellt wurde, ohne eine Bestandsaufnahme des aktuellen Projektstands vorzunehmen , ist eine der häufigsten Ursachen für das Scheitern von Projekten. Agilität garantiert keinen Erfolg; Es wird lediglich erwartet, dass die Sichtbarkeit und Transparenz des Projekts es den Beteiligten ermöglicht, fundierte Entscheidungen zu treffen.

In Scrum lehren wir Teams, kein „Risiko“ einzugehen, wo es ihnen nicht zusteht. Ihr Team hat zu Beginn nach bestem Wissen und Gewissen geschätzt, und im Laufe der Zeit stellen Sie und der Kunde fest, dass die Schätzungsfähigkeit des Teams sehr schlecht ist.

Die erste Frage, die ich dem PO stellen werde, ist, welche Risikominderung hatte er/sie, sollte ein Team wahrscheinlich falsch einschätzen? Ich denke, es ist allgemein anerkannt, dass technische Teams unabhängig von der Methode schlecht im Schätzen sind.

Als Nächstes haben Sie die Arbeitsgeschwindigkeit (Geschwindigkeit) des Teams im Vergleich zur ursprünglichen Schätzung verfolgt. Unabhängig von der von Ihnen verwendeten Technik ist die Geschwindigkeit letztendlich ein Verhältnis, das auf die ursprünglichen Schätzungen angewendet wird. Der Trend zeigt beispielsweise, dass das Team 72 % mehr Zeit benötigt als geschätzt. Daher sollte die Anwendung einer Velocity auf die ursprüngliche Schätzung Ihnen einen Hinweis auf das "reale" Zieldatum geben.

Scrum schreibt nicht offiziell vor, wie Teams schätzen und wie die Release-Planung durchgeführt werden sollte. Es gibt jedoch mehrere bewährte Muster, die funktionieren.

Grundprinzipien

1. Bringen Sie Ihr Produkt-Backlog auf ein Niveau, bei dem das Team ein Bauchgefühl dafür hat, was zu tun ist. Dies sollte sehr schnell und ohne vollständige Analyse erfolgen.

2. Das Team sollte dann alle PBIs mit einer relativen Skala anhand von Story Points oder T-Shirt-Größen schätzen (I Medium kann doppelt so groß sein wie Small). Theoretisch sollte ein PBI, der eine 2 ist, ungefähr doppelt so viel Aufwand/Zeit in Anspruch nehmen wie eine 1.

3. Wenn neue Elemente erstellt werden, sollte das Team diese auch schätzen. Das Team sollte immer noch anhand der ursprünglichen Skala schätzen und seine verbesserten Leistungen und Werkzeuge nicht berücksichtigen; Dies führt zu einem Verhältnis, das auf die Geschwindigkeit angewendet wird, was zu schwachen Ergebnissen führt.

4. Erstellen Sie Aufgaben in der Sprintplanung, um dem Team zu helfen, sich auf die Bereitstellung des PBI zu konzentrieren. Wenn Sie Aufgaben wirklich schätzen möchten, können Sie das tun, aber ich finde oft, dass dies keinen großen Mehrwert bringt.

5. Verfolgen Sie einfach, wie viel Arbeit das Team in einem Sprint geleistet hat, dh das Team hat es geschafft, 42 Story Points im Sprint abzuschließen. Das ist deine Geschwindigkeit.

6. Wenn Sie also 450 verbleibende Punkte in Ihrem Produkt-Backlog haben, werden Sie elf Sprints benötigen, um sie abzuschließen (450/42 = 11 - aufgerundet).

7. Informieren Sie das Management und den PO, dass das Team eine SCHÄTZUNG und NICHT TATSÄCHLICHE Zeiten angibt

Als Scrum Master besteht Ihre Herausforderung darin, dem Team zu helfen, zunächst seine Geschwindigkeit zu stabilisieren und dann seine Geschwindigkeit zu verbessern, indem er Verschwendung reduziert.

Es klingt für mich so, als ob Sie ein sehr Wasserfall-Scrum machen und dort auf Probleme stoßen. Ihr "Enddatum" sollte das Ende Ihres Sprints sein. Darüber hinaus sollte nichts begangen werden. Es hört sich so an, als würden Sie eine riesige Reihe von Geschichten über mehrere Sprints hinweg nehmen und sich zu weit entfernten Terminen verpflichten, um sie alle abzuschließen. Das ist ein Wasserfall, und ohne Planung und Design im Voraus im Wasserfallstil sehen Sie genau das Problem, auf das Sie stoßen.

In Perfect World Scrum ist die Zeit festgelegt, die Geschichten sind anpassbar. Dieses "Enddatum" sollte sich nicht ändern, nur die Anzahl der Storys, für die Sie sich verpflichtet haben, und nur während der Sprintplanung. Wenn Sie sich mitten im Sprint befinden und sich herausstellt, dass Ihre Schätzungen falsch waren, holen Sie Ihren Product Owner hinzu und verhandeln den Sprint-Rückstand auf der Grundlage des neuen Verständnisses. Das kann bedeuten, Dinge zurück ins Product Backlog zu verschieben, Stories auszutauschen oder im Extremfall den Sprint abzubrechen und neu zu beginnen. Wenn Sie Scrum folgen, sollte Sie ein vollständiger Abbruch eines Sprints nur ein oder zwei Wochen zurückwerfen. Nicht schlecht im Vergleich zum Wasserfall, wo ähnliche Probleme Sie Monate zurückwerfen können.

Eine der grundlegenden Prämissen agiler Methoden besteht darin, zu erkennen, dass wir schlecht im Schätzen sind und dass die Schätzung normalerweise umso falscher ist, je weiter sie entfernt ist. Das ist ein wichtiger Punkt hinter kurzen (2 bis 3 Wochen) Sprints. Sobald Sie anfangen, verbindliche Schätzungen abzugeben, die Monate im Voraus liegen, sind Sie wieder im Wasserfall und müssen wie ein Wasserfall planen und entwerfen.