In dem Lean Coffee Talk "Stakeholder-Management für Product Owner" am 03.06.2020 haben wir uns darüber ausgetauscht, wie du als Product Owner transparent und für die Stakeholder zufriedenstellend planen kannst. Hinterfragt wurde, ob du mit Story Punkten oder mit Aufwandsschätzungen in Personentagen arbeiten solltest.

In diesem Blogbeitrag erkläre ich dir, warum Projektplanung basierend auf der Schätzung von Personentagen wie das Glaskugel-lesen alter Schamanen anhaftet und wie die Grundzüge empirischer Forecasts funktionieren, mit dehnen du sehr gute Vorhersagen treffen kannst.

Möchtest du am nächsten Lean Coffee teilnehmen?

Dann folge mir auf Eventbrite und werden über neue Events informiert.

Ein großeres Projekt, Feature, Epic, .... wird gestartet und ein Anforderungskatalog wird erstellt. Basierend hierauf wird eine Aufwandsschätzung in Personentagen durchgeführt. Das Ergebnis: 100 Personentage. 

Welche Fragen können wir uns stellen?

1. Hat die Schätzung ein Senior oder Junior Entwickler geschätzt? 
2. Werden vornehmlich Senior oder Junior Entwickler das Vorhaben umsetzen? 
3. Wie groß ist das Team? Mehr Menschen bedeuten auch mehr Kommunikationsaufwand und Effizienzverlust.
4. Basiert ein Personentag auf 8 Arbeitsstunden?
5. Sind mit 8 Arbeitsstunden Brutto-Arbeitsstunden (inkl. Kaffeepause) oder Netto-Arbeitsstunden (100% hochkonzentrierte Arbeit) gemeint?
6. Wie effizient kann unter den gegebenen Arbeitsbedingungen überhaupt gearbeitet werden?
7. Haben die Entwickler bereits einen Risikopuffer eingerechnet oder hat dies erst der Projektleiter getan?
8. Wieviel Risikopuffer ist enthalten und wieviel ist "ok"?
9. Gibt es eine Definition was "fertig" bedeutet? Wenn Entwickler eine Schätzung pro Feature abgeben, sind darin dann auch Aufwände für Test, Dokumentation, Produktionsdeployment, etc. enthalten?
10. Wie werden im Verlauf des Projektes Veränderungen behandelt? Urlaube, Krankheiten, andere Teamveränderungen, Scope-Änderungen etc. machen eine stetig Neuplanung notwendig. 

1. Mit Story Punkten basierend auf den Fibonacci-Zahlen (1,2,3,5,8,13,21,…) wir die Komplexität eines Features bewertet und nicht der Arbeitsaufwand. Die Bewertung eines Features wird im gesamten Entwicklungsteam vorgenommen. Junior und Senior Entwickler tauschen sich hierbei aus und alle einigen sich auf einen Wert.
2. Die Schätzung fällt leichter und geht schneller, da in Relation zu einander geschätzt werden kann. Wurde einmal anhand von Referenzfeatures definiert, was z.B. ein Feature mit Komplexität 5 bedeutet, können andere Features in Relation zu dieser Referenz verglichen werden. So lassen sich auch große Mengen an Anforderung schnell schätzen.
3. Vorher ist noch zu definieren, was das Team unter „fertig“ versteht. Hierfür gibt es im Scrum die Definition of Done. Die Komplexitätsschätzung beinhaltet also nicht nur die reine Programmierleistung, sonder alles was in der Definition of Done für alle Features einmal transparent fest geschrieben wurde.
4. Da sich kein Entwickler darauf festlegen muss, wie viel Zeit für ein Feature benötigt wird, gibt es keinen unterschwelligen Druck und nicht das Bedürfnis sich mit Risikopuffern vor späteren Vorwürfen zu schützen. 
5. Einen ersten Forecast über die Gesamtdauer des Vorhabens kann ich nach drei Sprints treffen. Nach drei Sprints ist eine erste Durchschnittliche Velocity bekannt, also wie viele Story Punkte das gesamte Team pro Sprint im Durchschnitt schafft. Angenommen das Team schafft 25 SP und im Backlog stehen aktuell noch Backlog Items mit insgesamt 100 SP, dann wird das Team sehr wahrscheinlich noch mindestens 4 Sprints brauchen.
6. Für die Budgetplanung muss ich noch zusätzlich wissen, wie viel ein Sprint kostest. Eingerechnet werden sollten alle Kosten die gegen das Budget laufen. Im einfachsten Fall die Personalkosten. So kann es sein, dass ein Sprint 25.000 EUR kostet. Wenn ich bis zum vereinbarten Termin noch 7 Sprints Zeit habe, aber nur noch Budget für 6 Sprints, dann kann ich hier früh Transparenz schaffen.  
7. Den Forecast zum Umsetzungstermin und zum Budget kann und sollte ich nach jedem Sprint neu kommunizieren. Was kann den Forecast beeinflussen? a) Die Features werden detaillierter analysiert und die Schätzungen der Story Punkte kann sich dadurch ändern. b) Durch neue Erkenntnisse können Features in das Backlog neu aufgenommen oder entfernt werden. c) Die durchschnittliche Velocity ändert sich, weil das Team z.B. besser Zusammenarbeit und effizienter wird (Velocity steigt). Oder die Teamzusammensetzung ändert sich, weil jemand krank wird oder im Urlaub ist (Velocity sinkt).
8. Sollte ein neuer Forecast ergeben, dass mehr Budget benötigt wird als geplant ist, kann entweder weiteres Budget bewilligt werden oder es werden die weniger wichtigen Feature gestrichen.
9. Sollte ein neuer Forecast ergeben, dass der angeforderte Umsetzungstermin nicht gehalten werden kann, dann kann über eine Verschiebung des Termins oder über die Streichung von Features gesprochen werden. Zusätzliche Entwickler ins Team aufzunehmen ist oft keine gute Wahl, weil die Velocity dadurch oft erst einmal sinkt.  
10. Jeder Forecast kann transparent erläutert werden, es gibt keine geheimen Risikopuffer. So schaffst du Vertrauen.