In Teil 1 und Teil 2 zum Thema Schätzen in agilen Projekten habe ich Ihnen Planning Poker und Magic Estimation vorgestellt. In diesem dritten und letzten Teil nähern wir uns dem Thema No Estimation, was für Teams, die länger zusammenarbeiten und deren Stories überschaubar und relativ gleichförmig sind, eine gute Alternative zu anderen Schätzmethoden ist.
No Estimation
Gastbeitrag von Michael Kloss
Seit einiger Zeit verfolge ich viele Diskussionen im Netz, die sich damit beschäftigen, warum wir überhaupt schätzen sollten. Und in der Tat kann man sich Gedanken machen, ob dies nicht möglich ist. Da agile Methoden auf empirischen – also gemessenen – Werten basieren, gibt es immer Metriken, die messbar sind und die aus der Erfahrung heraus entstanden sind.
Wertet man diese empirischen Daten über einen längeren Zeitraum aus, dann kommt man zu einem interessanten Ergebnis: Die Werte sind konstant mit einer geringen Standardabweichung. Wie kann ich mir diese Erkenntnis zu Nutze machen?
Anzahl der User Stories pro Sprint ermitteln
Wenn ich über einen längeren Zeitraum die Anzahl der User Stories messe, die pro Sprint fertiggestellt wurden, bekomme ich ein Ergebnis, das besagt, wie viele User Stories ich in einen Sprint einplanen kann, ohne vorher die Storypoints geschätzt zu haben. Ich gehe dabei davon aus, dass im Mittel jede Story den gleichen Schätzwert bekommt. Die folgende Tabelle zeigt eine fiktive Auswertung von 12 Sprints:
| Sprint | User Stories | Sprint | User Stories |
|---|---|---|---|
| #1 | 10 | #7 | 7 |
| #2 | 13 | #8 | 13 |
| #3 | 9 | #9 | 14 |
| #4 | 14 | #10 | 15 |
| #5 | 16 | #11 | 14 |
| #6 | 8 | #12 | 12 |
Berechne ich den Mittelwert, bekomme ich den Standardwert von 12 User Stories pro Sprint mit einer Abweichung von 3 User Stories. Für einen Forecast der nächsten drei Sprints kann ich 36 User Stories im Normalfall, 27 User Stories im schlechtesten Fall und 45 User Stories im besten Fall angeben. Der Vorteil an diesem Verfahren ist, dass man ganz ohne große Schätztermine auskommt.
Kanban’s Cycle Time
Eine weitere Möglichkeit, die ich für Forecasts häufig nutze, ist die Cycle Time aus der Kanban-Methode. Die Cycle Time ist die gemessene Zeit vom dem Moment an, an dem erstmals die Arbeit an einer User Story gestartet wird, bis zu dem Zeitpunkt, an dem die Story fertig ist. Die durchschnittliche Cycle Time aller User Stories aus den letzten Sprints ist dann der Mittelwert.
Angenommen unser Team hätte also eine Cycle Time von 0,8 Tagen pro UserStory bei einer Sprintlänge von 2 Wochen. Dann ist der Forecast bei 10 Tagen / 0,8 = 12,5 UserStories pro Sprint und damit ergibt sich ein Forecast von 37 User Stories für die nächsten drei Sprints.
Warum macht das nicht jeder?
Es gibt natürlich einige Grundvoraussetzungen, damit dieses Verfahren funktionieren kann:
– das Team muss schon länger erfolgreich zusammenarbeiten
– die Stories müssen relativ gleichförmig geschnitten sein
– mindestens Messwerte aus 6 Sprints – besser sogar mehr – müssen vorliegen
Diese Voraussetzungen schränken die Verwendung von No Estimation ein. Während man Bedingung 1 und 3 leicht schaffen kann, sieht es mit Bedingung 2 schon anders aus. Es ist sehr schwierig Stories, in dem geforderten Maß gleichmäßig zu schneiden. Wenn Sie es schaffen, ist diese Schätztechnik jedoch eine echte Zeitersparnis.
Abschluss
In dieser 3-teiligen Serie habe ich Ihnen 3 Schätztechniken vorgestellt: Planning Poker, Magic Estimation und No Estimation. Jede der drei Techniken hat ihren eigenen Platz in einem Projekt. Während Planning Poker sich für User Stories für ein Sprint Planning gut eignet, ist Magic Estimation eher für gröbere und umfassendere Schätzworkshops das Mittel der Wahl. Arbeiten Sie bereites in einem Advanced Team, ist die Technik No Estimation die richtige Wahl für Sie.
