Der Projektausschuss möchte Epics mit Story Points schätzen und diese Epics dann in kleinere Storys aufteilen, in denen sich alle Punkte zur übergeordneten Story addieren. Abweichungen von späteren Schätzungen sind strafbar.
Wenn ich eine Schätzungssitzung für ein Dutzend großer epischer Geschichten mit den ziemlich großen Zahlen ab 20 Punkten abhalte, kommt diese Zahl auf 400 Punkte. Ich zerlege diese Epen später in kleinere Geschichten und schätze sie für einen Zuwachs. Ich stehe unter dem Druck meines Projektausschusses, bei diesen späteren Schätzungen nur sehr geringe Abweichungen zu haben. Beispielsweise sollten die kleineren Geschichten alle die Schätzung ihres „Eltern“-Epos ergeben, und alle kleineren Geschichten sollten weiterhin 400 ergeben.
Ich habe meine eigene Meinung dazu, frage mich aber:
Was machen andere in solchen Situationen? Ich bin mehr als glücklich, einen der Punkte zu klären, wenn es hilft.
Die Abweichung hier ist strafbar.
Das ist bedauerlich. Ihnen droht eine Bestrafung, weil sicher ist, dass es Abweichungen geben wird. Zu hoffen oder zu versuchen, eine Varianz nahe Null oder eine Varianz von Null zu haben, bedeutet, dass es möglich ist, dass wir die Zukunft genau und präzise vorhersagen können ... was wir nicht können. Genaue Schätzungen sind ein Oxymoron.
Zuerst müssen Sie verstehen, dass es einen echten Unterschied zwischen einer Schätzung und Ihren Planungswerten gibt. Eine Schätzung ist IMMER eine Spanne und Ihr Planungswert ist die Zahl, an der Sie Ihren Hut hängen. Mit anderen Worten, Sie schätzen, dass diese Aufgabe 10 bis 25 Tage dauern wird. Ihr Planungswert beträgt 19 Tage. Sieh den Unterschied?
Ihr Ziel hier ist es, einen Planungswert zu wählen, bei dem der größte Teil Ihrer Wahrscheinlichkeit hinter Ihnen und nicht vor Ihnen liegt, aber bei dem Sie nicht zu viel verschwendetes Fett einbauen. Die Wahl muss mit der Risikotoleranz Ihres Unternehmens übereinstimmen. Da Sie sich in einer Null-Varianz-Kultur befinden, bedeutet dies nicht viel Risikotoleranz, sodass Sie mit Ihren Schätzungen auf der fetten Seite liegen werden. Es ist teuer, aber sicher, auf diese Weise zu arbeiten.
Aber ich denke, Ihre eigentliche Herausforderung besteht hier darin, Ihre Organisation über die Realitäten der Schätzung, aleatorische Risiken und die unrealistische Erwartung dieses Konzepts der Nullvarianz zu schulen.
Bei einem bestimmten Projekt sollten die Schätzungen besser werden, wenn das Erfahrungsteam Erfahrungen und Kenntnisse über das jeweilige Projekt gewinnt. Dadurch ändert sich die Schätzung. Wenn Sie die Dinge aufschlüsseln, sollten Sie bessere Schätzungen erhalten, die möglicherweise der Schätzung für das größere Paket entsprechen oder nicht. Wenn die Toleranz für Abweichungen von der Schätzung des Originals gering ist, sollten Sie dem Lenkungsausschuss skalierte Schätzungen zur Verfügung stellen. Verfolgen Sie die tatsächlichen Summen, damit Sie wissen, was die Skalierung verbirgt. Wenn es sich um Planverschiebungen handelt oder die Abweichung ansonsten hoch ist, je früher Sie sauber werden, desto besser.
In vielen Branchen lässt sich sehr genau planen. Wenn Sie eine weitere Einheit bauen, wenn Sie zuvor Hunderte, Tausende oder Millionen davon gebaut haben, ist es einfach, genau abzuschätzen, wie lange es dauern wird. In diesen Fällen wird ein bekannter Prozess wiederholt und es ist kein Design, Experimentieren oder Nacharbeiten erforderlich. Tests, falls erforderlich, sollen sicherstellen, dass die Qualität erhalten bleibt, und führen selten zu Nacharbeiten.
Das Erstellen von Software ist ein völlig anderer Prozess. Sofern Sie keinen schlechten Prozess haben, besteht jede Einheit hauptsächlich aus Design, Experimentieren, Testen und Nacharbeiten. Alle diese Schritte sind schwer vorherzusagen.
Am Ende sollten Sie einmalige Komponenten bauen. Diese haben nicht die Zeitsicherheit, die man bei der Produktion der nächsten Einheit einer Serie findet.
Fragen Sie den Projektausschuss, ob er einen ähnlichen Mangel an Varianz in der Zeit, in der er seine Aufgabe übernimmt, akzeptieren würde.
Die bisherigen Antworten sind gut. Eines möchte ich hinzufügen: Behandle alle Schätzungen als unveränderlich.
Sie aktualisieren niemals eine Schätzung. Sie erstellen eine neue Schätzung.
Es gibt nie "die" Schätzung.
Es gibt „die Schätzungen“ und „die aktuellste Schätzung“.
Da Ihr Vorstand jedoch Wertschätzung mit Belohnung und Bestrafung verknüpft hat, haben sie den Zweck der Wertschätzung vereitelt und Informationen vernichtet. Es spielt keine Rolle, welche Schätzungspolitik oder welcher Prozess verwendet wird, da der Vorstand einen direkten negativen Anreiz geschaffen hat, alle Schätzungen zu untergraben.
Ihre rationalste Strategie ist jetzt, aufzuhören, Ihre zweitrationalste ist, sich auf aggressives Sandbaging, Feilschen, Anwaltstätigkeit und andere CYA-Aktivitäten einzulassen.
Wie für:
Beispielsweise sollten die kleineren Geschichten alle die Schätzung ihres „Eltern“-Epos ergeben, und alle kleineren Geschichten sollten weiterhin 400 ergeben.
Das wird nicht passieren. Der Unpacking-Effekt zeigt, dass Schätzungen, wenn sie aufgeschlüsselt werden, größer werden.
Ihr Vorstand ist aus ihren kollektiven Kürbissen. Schätzungen sind keine Garantien, und die Genauigkeit von Schätzungen in jedem Prozess (aber insbesondere in iterativen Prozessen wie Scrum) ist eine Funktion sowohl der unvermeidlichen Änderungsanforderungen als auch eines variierenden Unsicherheitskegels.
Der Zweck der Schätzung von Epics besteht darin, einen groben Überblick über den Projektzeitplan zu geben und eine Priorisierung der Storys zu ermöglichen, um einen optimalen Wert für jeden Meilenstein oder das angestrebte Versanddatum zu erzielen.
Es liegt in der Natur von Epics, dass der Unsicherheitskegel extrem groß ist, und die anfänglichen Schätzungen (die keine Garantien sind) haben nicht die Genauigkeit der Story-by-Story-Schätzungen, die zu Beginn jedes Sprints vorgenommen werden.
Die Projektschätzung ist eine Projektion und eine Richtlinie zur Messung der Varianz. Der Projektplan kann und sollte dem gleichen Inspektions- und Anpassungszyklus unterliegen wie der Rest Ihres Prozesses. Der Vorstand kann dann die Theory of Constraints verwenden , um den Zeitplan, den Umfang oder die Ressourcen nach eigenem Ermessen anzupassen.
Stehen die Story Points überhaupt in Beziehung zwischen der anfänglichen Schätzung und späteren Sitzungen?
Ja und nein. Obwohl es Abweichungen zwischen der anfänglichen Projektion und der iterativen Merkmalsbereitstellung geben kann, sollte die Abweichung im Idealfall in eine vernünftige Größenordnung fallen. Wenn dies nicht der Fall ist, was nicht ungewöhnlich ist, dann ist dies einfach ein Beweis dafür, dass die ursprüngliche Schätzung falsch war und überarbeitet werden sollte.
Eine andere Sichtweise ist, dass die anfängliche Schätzung eine Basislinie ist, gegenüber der Sie die Varianz identifizieren . Was Sie mit dieser Abweichung unternehmen, liegt ganz bei Ihnen. In einem gut geführten Scrum-Projekt könnte man:
Das eigentliche Problem hier ist kulturell. Sie haben ein Command-and-Control-Projektboard, das die iterative Entwicklung als Königsweg betrachtet. Es ist nicht.
Das Erkennen von Abweichungen ist ein wünschenswertes Ergebnis einer effektiven Projektsteuerung. Die Bestrafung des Boten führt nicht zu Transparenz oder Sichtbarkeit; es kann nur zu CYA-Verhaltensweisen führen wie:
Der Zweck des Vergleichs Ihres aktuellen Fortschritts mit einer anfänglichen oder aktualisierten Planungsschätzung besteht darin, diese Abweichung zu identifizieren. Wenn Varianz bestraft wird, wird sie nicht identifiziert. QED
"Abweichungen bei späteren Schätzungen sind strafbar."
AUTSCH!!!!
Hier gibt es viele großartige Antworten, aber ich möchte mich auf dieses Problem konzentrieren, da diese Art von Einstellung Projekte, Teams und Produktivität zerstört.
Schätzung ist genau das ... eine Schätzung. Es ist kein Tatsächliches. Die Welt der Softwareentwicklung ist voller Komplexität und Ungewissheit und dies sollte von der Wirtschaft akzeptiert werden. Dem Management muss die Frage gestellt werden: "Was werden Sie tun, um eine Überschreitung der Schätzung abzumildern?" In Scrum lehren wir Teams, keine Risiken einzugehen, die für das Geschäft sind, diese sind Zeit, Geld, Budget.
Teams bauen Software und das ist ihre Fähigkeit. Sie sind keine Projektmanager und auch keine Schätzer. Sie können helfen, Schätzungen zu unterstützen, aber es ist einfach so.
Ich fordere das Management oft in Bezug auf Verkäufe und Budgets heraus. Schätzen sie ihre zukünftigen Umsatz- und Budgetzahlen auf den Tag genau ein? Es ist NEIN ; Wenn sie also als Management nicht schätzen können, wie um alles in der Welt erwarten sie dann, dass andere Leute genau schätzen?
Ich empfehle, einen erfahrenen Coach hinzuzuziehen, der Ihnen dabei hilft, Ihr Management über Schätzungen aufzuklären, da es viele, viele Faktoren gibt, die zu groß sind, um sie hier zu diskutieren. Der Coach soll helfen, die Denkweise Ihrer Manager zu ändern.
Andreas klar