„Ich würde fast ne Kiste Bier drauf wetten, dass nach der Umstellung auf Story Points kein Product Owner mehr eine brauchbare Übersicht bzgl. des geschätzten Volumens der „Aufträge“ vs. verfügbare Kapazität haben wird. Es wird keinen Forecast mehr möglich sein. Wenn aber alle der Meinung sind, das geht auch so, dann bitte ;-)“
Solche Einwände hört man immer wieder bei der Umstellung von stundenbasiertem Schätzen des Aufwands zum relativen Schätzen der Größe einer Aufgabe mit Story Points.
Doch zunächst einen Schritt zurück.
Wozu verwenden wir eigentlich Schätzungen?
- Eine Anfrage kommt rein und ein Auftraggeber möchte Wissen was die Umsetzung kosten würde: Die Anforderung ist häufig noch nicht detailliert spezifiziert, es ist unklar, ob es überhaupt beauftragt wird und die Kostenindikation wird zeitnah benötigt. Hier soll schnell eine Kostenindikation aus dem Arm geschüttelt werden.
- Man möchte Wissen wann ein Feature umgesetzt wird, welche Features für ein Release geplant werden. Dazu muss man Wissen was das Team unter den bestehenden Rahmenbedingungen (Teamgröße & Prozesse) in welcher Zeit umsetzen kann und welche Auswirkungen sich durch Umpriorisierungen und Verschiebungen ergeben.
- Durch die Relation von Business Value zur Komplexität der Umsetzung wird eine Priorisierung ermöglicht.
- Das Team kann ein verlässliches Commitment für den nächsten Sprint geben
- Schätzungen dienen im Team, um Kommunikation über die vom PO erwartete Lösung zu führen und diese genauer zu spezifizieren, sowie ein gemeinsames Verständnis zu erreichen.
Das Schätzen auf Stundenbasis und die Aggregation zu Manntagen hat viele Nachteile. Es müssen alle Teilschritte vorher bekannt sein und es muss vorab auch festgelegt werden wer eine Aufgabe erledigt, da Menschen in Abhängigkeit von ihrer Erfahrung bzw. Routine unterschiedlich schnell sind. So verursachen die Schätzungen einen hohen Aufwand und sind dennoch ungenau. Das zeigt die Erfahrung aus einer Vielzahl von Projekten. Auch Reportings auf Stundenbasis haben keine Aussagekraft darüber welches Feature tatsächlich fertiggestellt ist und welche Komponenten noch nicht. Oft werden mit Blick in die Glaskugel irgendwelche Dummy Werte eingetragen, damit automatisierte Reportingtools funktionieren. Schätzungen auf Stundenbasis sind daher kaum geeignet um die Bedarfe 1-5 zu befriedigen.
Warum wollen wir Scrum Master und Agile Coaches, dass User Stories in Story Points geschätzt werden? Warum haben relative Schätzungen mit Story Points eine höhere Aussagekraft, sind verlässlicher und schneller? Die Vorteile sind Gesprächspartnern, die es noch nicht selber erlebt haben, meist schwierig zu vermitteln. Als Autoaffiner Mensch, der gerade ein Haus baut kam wir folgende Idee zur Erklärung….
Beispiel zum Schätzen mit Story Points
Stellen wir uns vor ein Team schafft pro Sprint alles was in eine Garage passt. Das wissen sie aus Erfahrung und das wird auch nach jedem Sprint gemessen. Die Referenzstory bei diesem Team ist ein VW Golf. Das Team kann über relatives Schätzen zur Referenz Story „VW Golf“ sehr schnell die Komplexität der übrigen Backlog Einträge schätzen und bestimmen was in den Sprint reinpasst.
Mein Beispiel:
| Velocity (gemessen)
20 Story Point maximal Sprintdauer 4 Wochen Kosten: Teammonat: 40.000 € D.h. Kosten pro Story Point = 2.000 € |
Backlog (relativ geschätzt in Story Points)
Anhänger: 2 |
|---|
Anhand der gemessenen Velocity des Teams und der relativen Schätzung kann das Team einen Commitment abgeben. Die Raodmap Planung wäre wie folgt:
- Sprint: VW Golf + Smart + Fahrrad = 19 SP
- Sprint: Motorrad + Assistenzsysteme: 16 SP
- Sprint: Motor + Anhänger = 15 SP
- Sprint: Karosserie + Integration = 16 SP
- Sprint: Audi A4 = 20 SP
Erkenntnisse aus diesem Beispiel
- Das Backlog wäre nach 5 Sprints abgearbeitet.
- Der BMW 5er war zu groß für einen Sprint. Die User Story wurde entsprechend geschnitten.
- Anhand der Roadmap, die nach jedem Sprint aktualisiert wird, ist immer transparent was fertiggestellt wurde und was noch offen ist.
- Auch eine Aussage zu den Kosten kann gemacht werden. So kostet die Herstellung des Audi A4 in diesem Beispiel 40.000 €.
Durch neue User Stories im Backlog kann sich die Priorität und damit die Reihenfolge der Abarbeitung verändern. Dies würde in der Raoadmap berücksichtigt werden, sodass zu jederzeit Transparent ist was wann gemacht wird.
Bei klassischen Schätzungen auf Stundenbasis müssten die Teammitglieder eine Vielzahl von einzelnen Komponenten bewerten. Z.B. Reifen, Stoßstange, Höhe der Karosserie, Spiegel, etc.
Der Aufwand und folglich die Dauer sind sehr hoch, zudem auch die Gefahr, dass selbst Experten etwas vergessen. Diese Schätzungen sind daher meist viel ungenauer und werden nicht angepasst. Auch der Blick auf den verbleibenden Aufwand in Stunden sagt nicht aus welche Komponenten tatsächlich fertig sind und ausgeliefert werden können (also einen Business Value generiert haben), sondern erlaubt im übertragenen Sinne eine Aussage wie diese: „45 Zentimeter vom Fahrzeug sind fertiggestellt, 4 Meter fehlen noch“.
In diesem Sinne viel Spaß beim Schätzen mit Story Points!
