Agiler Adventskalender: Schätzungen in idealen Personentagen

Wir schätzen, dass das Thema, das sich hinter dem 11. Türchen unseres Agilen Adventskalenders verbirgt, vielen von euch schon einmal untergekommen sein dürfte. Daher wünschen wir euch viel Spaß beim Erkunden unserer Tipp auf die Frage:

Ich verstehe nicht, wieso wir nicht in idealen Personentagen schätzen sollten?

Schätzungen in idealen Personentagen

Schätzungen in „idealen Personentagen“ sind immer noch verbreitet. Der „ideale Personentag“ korrigiert für planbare Ereignisse wie Meetings oder geplante Abwesenheiten, setzt aber sonst – wie der Name schon sagt – einen „idealen Verlauf“ voraus. Der Einbau von Korrekturfaktoren ist hier zwar ebenfalls möglich; ich möchte dennoch darstellen, wieso der Einsatz dieses Konzeptes nicht die „ideale Idee“ ist und auf die Vor- und Nachteile eingehen.

Es gibt diverse Schätzverfahren im Agilen Kontext: Planning Poker, T-Shirt Sizes, Magic Estimation, Drei-Punkt-Schätzung, etc. In der morgigen Ausgabe des Agilen Adventskalenders werdet ihr mehr dazu erfahren.

Relative Schätzungen

Diesen Methoden ist im Agilen gemein, dass es sich um „relative Schätzungen“ handeln sollte. Was bedeutet das? 

Ein Beispiel: Die Kompetenzen in einem Entwicklerteam sind immer unterschiedlich verteilt. Person 1 hat die Anforderungen in dem Ticket bereits einmal gelöst, Person 2 nicht. Es bringt also wenig zu sagen: „Das Ticket dauert drei Tage“, denn dann müsste ich wissen, wer dieses Ticket bearbeitet – und das im Vorhinein für alle Tickets festlegen.

Bei relativen Schätzungen geht es daher nicht um den reinen Zeitaufwand, sondern um den Faktor „Effort“. Hier muss auch mit einem Missverständnis aufgeräumt werden, dem auch ich lange unterlegen bin: Geschätzt wird nicht die Komplexität, sondern der Effort! Komplexität ist lediglich eine Komponente, die der Effort beinhaltet. Der Erfinder der Story Points erklärt dieses Missverständnis in seinem Blogpost Story Points Estimate Effort Not Just Complexity.

Nehmen wir das Planning Poker. Das Team spricht über das Ticket und einigt sich auf eine Zahl an „abstrakten“ Story Points. Damit ist aber nichts über den konkreten Zeitaufwand gesagt, denn der hängt davon ab wer es am Ende macht und was auf dem Weg dahin passiert.

Die Faktoren von Effort

Wichtig dabei: Effort ist keine eindimensionale Komponente. Vielmehr umfasst sie eine Vielzahl an Faktoren, die am Ende gegeneinander abgewogen werden und zu einer Schätzung führen: 

1. Komplexität: Wie „komplex“ ist die Anforderung, was die Umsetzung angeht?
2. Aufwand: Welcher reine Aufwand steht dahinter?
3. Risiko: Welche bekannten Risiken begegnen einem bei der Umsetzung?
4. Unsicherheit: Was wissen wir noch gar nicht, muss aber eingepreist werden?

Doch wieso kann ich dieses Problem jetzt nicht in „idealen Personentagen“ lösen?

„Ideale Personentage“

Theoretisch kann man das versuchen und man kann auch Korrekturfaktoren einbauen, die Martin Fowler als „load factor“ definiert: https://martinfowler.com/bliki/IdealTime.html

Aber man kauft sich immense Nachteile ein, die am Ende vielleicht zu einem Ergebnis führen, das man gar nicht möchte. 

Der einzige Vorteil, den ich sehe, ist, dass man den Stakeholdern eine klare Dauer- und Ressourcenplanung im klassischen Sinne bietet. Denn die Schätzungen sind weniger abstrakt, hängen an konkreten Personentagen.

Die Nachteile sind aber erheblich:

• „Ideale Tage“ gibt es nicht. Selbst, wenn man Korrekturfaktoren einbaut und dann „actual days“ nimmt. Wie korrigiere ich für die „Unknown Unknowns“, ohne mir selbst in die Tasche zu lügen und lediglich einer Illusion hinterherzulaufen, die mir klare Planbarkeit suggeriert?
• Man ist gezwungen im Vorfeld festzulegen, wer welches Ticket macht; das konterkariert Wissensverteilung und bringt den Truck-Faktor mit sich.
• Die Missverständnis-Gefahr, was eine Schätzung eigentlich ist, ist sehr hoch: „Ihr habt mir gesagt, es dauert drei Tage, jetzt sind es vier. Woran liegt es?“ 
• Es findet oft keine echte Auseinandersetzung mit den oben angesprochenen Faktoren statt. Denn in der Softwareentwicklung ist eine Aussage „Dieses Ticket dauert drei Tage“ aufgrund des oben beschriebenen Effort-Bestandteils ein Anti-Pattern, da zu viele Komponenten zusammenspielen.
• Man öffnet einer klassischen Ressourcenplanung Tür und Tor und untergräbt agile Prinzipien.

Okay, das verstehe ich alles, aber mein Stakeholder will es genauso haben! Was nun?

Argumentationshilfen

Sucht das Gespräch und klärt auf! Am Ende geht es einem Stakeholder um „Planungssicherheit“ und das Wissen, was mit seinem Geld passiert. Erfragt die Bedürfnisse, die hinter dieser Forderung stecken und handelt aus, wie diese Bedürfnisse erfüllt werden, ohne agile Prinzipien zu verletzen. Mit „idealen Personentagen“ werdet ihr auf Dauer fast immer danebenliegen. Mit „actual days“ sicher nicht mehr ganz so häufig, aber wie Martin Fowler so schön sagt: „Using ideal time fell out of favor since StoryPoints were easier to calculate, less likely to be abused, and every bit as accurate.“

Erklärt die Vorteile der Abstraktion von relativen Schätzungen und dass sich auch damit ein sehr guter Forecast betreiben lässt, wenn sich die Velocity eingependelt hat oder man einen Flow aufbaut, der über Metriken einen Forecast zulässt. Wichtig dabei ist, dass die Metriken transparent sind und damit gegenseitiges Vertrauen geschaffen wird.

Agilität und Planung widersprechen sich nicht. Die Planung läuft nur anders! (Wer mehr dazu wissen will, dem ist das Buch von „Predicting the Unpredictable“ von Johanna Rothmann zu empfehlen.)

Mein Tipp zum Thema Schätzungen und Planning: Lest den Klassiker von Mike Cohn: Agile Estimating And Planning.

Wie schaut es bei Euch aus? Wie schätzt ihr? Was sind Eure Erfahrungen?