Die Fibonacci-Folge soll Entwickler bei Projektschätzungen unterstützen. Die Sorge ist, dass wir ständig sehen, dass das Management die aus Fibonacci-Folgenschätzungen abgeleiteten Punkte verwendet, um die Projektgeschwindigkeit oder, was noch wichtiger ist, die Entwicklereffizienz zu bestimmen. Was offensichtlich sinnvoll ist, wenn man bedenkt, dass der Zweck jeder gegebenen Projektschätzungsmethodik darin besteht, die Geschwindigkeit zu schätzen und die Trends zu bemerken.
Das Problem hier wird deutlich, wenn man bedenkt, dass ein Entwickler in einem zweiwöchigen Sprint leicht nachweisen könnte, dass er 1-zu-2-Punkte-Backlogs/Aufgaben im Wert von 16 Punkten zerschlagen hat, und dann vernünftigerweise zwei Sprints für eine einzelne 8-Punkte-Aufgabe benötigt. Jetzt muss sich diese Entwicklerin verteidigen, warum ihre Geschwindigkeit um 400 % gesunken ist.
Nun, sie sollte bei Projektschätzungen besser werden.
Das ist irrelevant. Wenn man bedenkt, dass der ganze Sinn der Fibonacci-Skala darin besteht, ein Gefühl der exponentiellen Anstrengung zwischen den Aufgaben zu vermitteln, ist eine 1-Punkt-Aufgabe gegenüber einer 8-Punkte-Aufgabe ein Unterschied von 800 %. Im obigen Fall hat der Entwickler tatsächlich unterschätzt, aber das Management sieht quantitativ einen Leistungseinbruch.
Dann muss das Team definieren, was die verschiedenen Punkte bedeuten.
Die einzige konkrete Definition, über die sich ein Team einigen könnte, ist, wie viel Zeit eine 1-Punkte-Aufgabe im Vergleich zu einer 8-Punkte-Aufgabe benötigt, aber wenn wir anfangen, Zeitrahmen dafür festzulegen, verfehlen wir den Zweck dieses agilen Projekts Schätzungsmethodik; wir könnten genauso gut auf pauschale Zeitschätzungen zurückgreifen.
Nun, dann muss das Management verstehen, dass die Punkte exponentiell sind und dass 16 Punkte in einem Sprint im Vergleich zu 8 Punkten in einem anderen Sprint nicht unbedingt bedeuten, dass die Geschwindigkeit gesunken ist.
Warum machen wir uns dann die Mühe, die Geschwindigkeit zu messen, wenn sie sowieso so relativ ist? Wenn wir dem Management die Komplexität jeder Aufgabe in den Sprints verständlich machen wollen, warum sollte man dann überhaupt ein Punktesystem verwenden, das konsequent zur Messung der Geschwindigkeit verwendet wird? Um sicherzugehen, warum beginnen Entwickler nicht damit, ihre Punkte zu überschätzen, damit sie mehr Punkte pro Sprint einlösen? All diese Was-wäre-wenn und "es kommt darauf an" klingt nicht sehr agil.
Geschwindigkeit war nie als Leistungsmaß gedacht. Es wurde speziell entwickelt, um Teams dabei zu helfen, ihre Kapazität in zukünftigen Sprints einzuschätzen. Wenn es verwendet wird, um die Leistung von Teams zu kritisieren, dann haben Sie ein Problem.
Dies unterstreicht nicht, dass es ein Problem mit der Fibonacci-Skala gibt, sondern wie wichtig es ist, dass alle Beteiligten über den verwendeten agilen Ansatz aufgeklärt werden.
Agile war noch nie nur eine Frage der Entwicklungsteams. Es ist etwas, das die gesamte Organisation verstehen und sich darauf einstellen muss.
Jetzt muss sich diese Entwicklerin verteidigen, warum ihre Geschwindigkeit um 400 % gesunken ist.
Wenn der Entwickler Geschwindigkeitsänderungen im Sprint allein durch Sprintstatistiken verteidigen muss, ist das völlig falsch. Das Team wird wissen, wenn sich jemand nicht die nötige Mühe gibt.
Es könnte sein, dass ein gleitender Durchschnitt von drei oder fünf Sprints ein realistischeres Maß sein könnte.
Hier ist jedoch eine andere Idee, die ich gerne fördern möchte. Punkte sind eine grobe Schätzung der Komplexität im Verhältnis zueinander. Wenn das Team mit einer hohen Punkteschätzung endet, dann ist das ein Hinweis darauf, dass die Geschichte wahrscheinlich zu groß ist.
Wenn eine Story eine Punkteschätzung erhält, die ungefähr 50 % der typischen Geschwindigkeit eines Sprints entspricht, dann sollte das ein Flag sein. Wenn die Entwicklung am Ende mehr als 50 % des Sprints in Anspruch nimmt, werden Sie dann tatsächlich Zeit haben, es im Sprint abzuschließen, wenn Fehler gefunden werden oder ein anderer Blocker auftaucht?
Versuchen Sie daher, diese Geschichte zu verfeinern, wenn sie diese Art von Schätzung erhält.
Allerdings ist es nicht immer so, dass diese Dinge vorhersehbar sind, vielleicht treten die Probleme auf, nachdem die Entwicklung begonnen hat. Ich würde meine Teams immer dazu ermutigen, hier schnell zu scheitern, die Geschichte aufzugeben und dieses Wissen zum BA zu bringen, um weitere Geschichten zu erstellen, und nicht zu versuchen, alles in der ersten Geschichte zu klären. Behandeln Sie das Original als Spitze.
Grundsätzlich erhalten Sie einen guten, konsistenten Fluss von Geschichten und daher eine ziemlich gleichmäßige Geschwindigkeit, wenn Sie es immer mit Geschichten von 1, 2 oder 3 Punkten zu tun haben, vielleicht die ungeraden 5. Dies sollte auch Ihren letzten Punkt bezüglich der Versuchung lösen die Punkte zu übertreiben.
Todd A. Jacobs
8 Protonen
Todd A. Jacobs
Bart van Ingen-Schenau