Besonders häufig tritt der Planungsfehler bei der Schätzung von Aufgaben in der Softwareentwicklung auf. Allerdings scheinen agile Schätzmethoden wie Planungspoker etc. nicht darauf ausgelegt zu sein, dieses Problem zu vermeiden.
Was tun Sie also, um den Planungsfehler bei der Schätzung von Aufgaben oder Tickets in IT-Projekten zu vermeiden? Gibt es Produktmanagement-Methoden oder Best Practices, die darauf abzielen, diesen weit verbreiteten Irrtum zu vermeiden?
Planning Poker wurde entwickelt, um eine Form der Referenzklassenprognose zu verwenden (oder kann zumindest so verwendet werden, dass es dazu gehört).
Beim Schätzen mit Planungspoker können Sie eine Art „Basis“-Ticket auswählen, das etwa 1 Arbeitspunkt darstellt, und dann alle anderen Tickets als „etwa doppelt so schwer“ für 2 Story-Punkte oder „wahrscheinlich 10-mal so schwer“ einschätzen " für 13 Story Points oder "viel einfacher" für 1/2 Story Point.
Indem Sie von einem Basisticket aus schätzen und immer nur auf der Grundlage eines Vergleichs mit diesem planen, werden alle Schätzungen relativ. Dies sollte eine ziemlich große Menge an Voreingenommenheit eliminieren; Sie denken nicht an die Zeit , sondern an die vergleichende Größe , was Menschen viel besser können.
Um dann zu entscheiden, wie weit Sie kommen können, sehen Sie sich die Erfolgsbilanz des Teams für „Story Points per Sprint“ an und füllen etwas Vergleichbares auf. Wenn das Team besser wird, schätzt es weiter auf die gleiche Weise, aber die „Story Points per Sprint“ steigen, sodass auch die Menge an Arbeit wächst, die es übernimmt, ohne jemals neu kalibrieren zu müssen.
Diese Methode funktioniert, solange Sie die Leute immer wieder daran erinnern, dass Story Points keine Zeitmaße sind, sondern Komplexität zu einem Bezugspunkt, und dass sie zu keinem Zeitpunkt zwischen den beiden umrechnen dürfen. Es funktioniert nicht mehr in dem Moment, in dem Sie entscheiden, dass ein Story Point eine Stunde oder ein Tag oder ein anderes Zeitmaß ist, da Sie sofort in alle von Ihnen (und dem Artikel) erwähnten Schätzungsfallen zurückfallen.
Sie können Voreingenommenheit nicht „vermeiden“. Es ist immer da. Sie können es nur minimieren, indem Sie eine Aufgabe mit mehreren verschiedenen Methoden schätzen und sich auf probabilistische Schätzungen im Vergleich zu deterministischen Schätzungen konzentrieren. Und selbst dann wissen Sie nur, wie gut Sie die Verzerrungen aufgearbeitet haben, wenn Sie Ihre Ist-Werte mit Ihren Planwerten vergleichen können und Sie über eine relativ große Anzahl von Vergleichsbeobachtungen verfügen. Dies setzt voraus, dass Sie eine äußerst zuverlässige Methode zur Verfolgung und Kontrolle Ihrer tatsächlichen Werte haben, und das ist eine große Annahme, die wahrscheinlich nicht sehr wahr ist.
Wie bei allen menschlichen Vorurteilen gilt: Je mehr Sie glauben, sie unter Kontrolle zu haben, desto voreingenommener sind Sie.
Gemäß dem Wikipedia-Eintrag „Planungsfehlschluss“ :
Der Planungsfehler ... ist ein Phänomen, bei dem Vorhersagen darüber, wie viel Zeit benötigt wird, um eine zukünftige Aufgabe zu erledigen, eine optimistische Tendenz aufweisen und die benötigte Zeit unterschätzen.
Unterschiedliche agile Frameworks verwenden unterschiedliche Metriken, aber die häufig verwendeten Velocity- und kumulativen Flussmetriken sind die typischen Leitplanken zur Minderung von Planungsverzerrungen. Es gibt sicherlich andere Metriken, aber ich werde kurz auf Geschwindigkeit eingehen, weil ich denke, dass sie das Anliegen am ehesten anspricht.
Die Geschwindigkeit ist eine Metrik, die historische Lieferraten betrachtet und einen gleitenden Durchschnitt oder andere statistische Funktionen verwendet, um Störungen zu glätten. Die Velocity-Metrik ist probabilistisch, und obwohl sie oft am besten mit einer Basisreferenzklasse funktioniert, um die Metrik zu verankern, ist sie in der pragmatischen Verwendung tatsächlich weniger empfindlich als man denkt. Die eigentliche Determinante dafür, wie zuverlässig die Geschwindigkeit als Vorhersagemetrik ist, ist die Konsistenz des Schätzprozesses.
Der Schlüssel zum weithin anerkannten Erfolg von Velocity in der agilen Planung ist ein konsistenter Schätzprozess. Es spielt eigentlich nur eine untergeordnete Rolle, ob der Schätzprozess optimistisch oder pessimistisch ist oder die Referenzklasse insgesamt ignoriert, solange der Schätzprozess auf ähnliche Weise über Iterationen hinweg angewendet wird. Über ein ausreichendes Zeitfenster wird ein konsistenter Schätzprozess in Richtung der nachhaltigen Lieferrate tendieren.
Während ein konsistenter Schätzprozess für zuverlässige Prognosen unerlässlich ist, bedeutet dies nicht, dass sich der Schätzprozess Ihres Projekts nicht ändern oder verbessern kann. Die bemerkenswerte Einschränkung hier ist, dass iterative oder inkrementelle Verbesserungen des Schätzprozesses kleine Störungen in den Lieferraten erzeugen, aber im Allgemeinen klein genug sind, um von der Glättungsfunktion geschluckt zu werden.
Als damit verbundene Einschränkung ist es auch möglich, radikale Änderungen (hoffentlich Verbesserungen!) am Schätzprozess vorzunehmen. In diesem Fall müssen Sie entweder historische Daten verwerfen oder einen „Fudge-Faktor“ anwenden, um die Änderungen in der Methodik zu berücksichtigen. Dies kann kurzfristig zu einer geringeren Prognosezuverlässigkeit der Metrik führen, kann sich jedoch oft lohnen, wenn es zu einer höheren nachhaltigen Zuverlässigkeit bei der Erfüllung von Prognosen führt.
Es ist nicht das gemeinsame Schätzen beim Planen von Poker, das so viel hilft (obwohl das individuelle Vorurteile reduzieren kann). Es ist der Geschwindigkeitsverfolgungsteil, mit dem Sie historische Daten anwenden können, um bei zukünftigen Schätzungen zu helfen.
Wenn wir beispielsweise im vorherigen Sprint versucht haben, 50 Punkte Arbeit zu erledigen, aber nur 40 geschafft haben, dann liegt unsere Rate wahrscheinlich näher bei 40 als bei 50.
Hier ist ein weiteres Beispiel für die Verwendung historischer Daten zur Verbesserung der Genauigkeit von Schätzungen (komplexer in Bezug auf die Datenerfassung; außerdem werden Wahrscheinlichkeitsverteilungen verwendet).
Andere Methoden, die ich gesehen habe, funktionieren:
Vergessen Sie nicht die Idee der Schätzungskonvergenz (frühe Schätzungen sind weit entfernt und werden sich im Laufe der Arbeit immer weiter verbessern).
Erik
Asmaier