Agile Series: Messen statt Schätzen mit No Estimation

Foto des Autors
Thorsten Kamann

Mit No Estimation können Sie in agilen Projekten messen, wieviele User Stories Sie und Ihr Team in einem Sprint schaffen. Aus diesen empirischen Daten ermitteln Sie einen Forecast für die nächsten Sprints. Und das ohne eine User Story mit Storypoints schätzen zu müssen.

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:

SprintUser StoriesSprintUser Stories
#110#77
#213#813
#39#914
#414#1015
#516#1114
#68#1212

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.

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Mit dem MVP-Canvas den Umfang des Minimum Viable Product bestimmen

Mit dem MVP-Canvas den Umfang des Minimum Viable Product bestimmen

Wenn verschiedene Beteiligte aus Marketing, Vertrieb, Fachabteilungen und Software-Entwicklung zusammensitzen und ein neues Produkt vorbereiten, dann kommt es häufig zu ...
Agile Series: Warum schätzen in agilen Projekten wichtig ist und wie es gut funktioniert

Agile Series: Warum schätzen in agilen Projekten wichtig ist und wie e...

Für viele ist es eine eher unbeliebte Aktivität im Rahmen eines Softwareentwicklung-Projekts - für mich schon deshalb ein Lieblingthema: Schätzen ...
Kamil Sokolski bei einem ruhigen Gespräch mit einem Arbeitskollegen im Conciso Workgarden im agilen Kontext. Zusätzlich wird das Conciso Logo in der unteren rechten Ecke abgebildet. Das Bild wird in dem Wissensbeitrag "Agilität ganzheitlich denken, statt nur „PS auf die Straße bringen“." genutzt.

Agilität ganzheitlich denken, statt nur „PS auf die Straße zu bringen“...

Agile Coach Kamil Sokolski erklärt, weshalb es wichtig ist, Agilität ganzheitlich zu denken ...