In Idealtagen oder in Story Points schätzen?

Mit der Schätzung in Story Points ([glossary id=’1585′ slug=’story-points’ /]) und in Idealtagen ([glossary id=’1588′ slug=’idealtag’ /]) habe ich nun zwei verschiedene Ansätze für agiles Schätzen vorgestellt. Welche sollte nun im Projekt benutzt werden? Beide haben dabei eindeutige Vor- und Nachteile. Die passende Auswahl muss, wie bei fast allen beschriebenen Techniken, im Einzelfall für das spezifische Projekt getroffen werden und zu dem geplanten Projektteam passen.

Einige der Vor- und Nachteile möchte ich an dieser Stelle etwas detaillierter hervorheben. Unter Umständen helfen diese Punkte auch bei der Argumentation der Methodik, bei der Überzeugung des Kunden oder des Teams.

Story Points forcieren gemeinsames Schätzen

Ein großer Vorteil von Story Points ist die Fokussierung auf die gemeinsame Schätzung und die Übernahme der Verantwortung für diese Schätzung durch das gesamte Team. Jeder Anforderung muss ein konkreter Schätzwert zugewiesen werden.  Damit sind sie sehr wichtig für das gedankliche Commitment zum Projekt.

Idealtage hingegen werden oft fälschlicherweise auf die einzelnen Gewerke verteilt. So schätzt der Entwickler seinen geplanten Aufwand unabhängig vom Designer und vom Konzepter und anschließend werden alle Schätzwerte aufsummiert. Hierdurch findet weniger Gedankenaustausch über die Details der Anforderung statt und jedes Teammitglied trägt lediglich die Verantwortung für seinen Anteil, nicht aber für das große Ganze.

Schätzung in Story Points ist meist schneller

Die Schätzung in Story Points geht wesentlich schneller, da lediglich die Relation zu anderen, bereits geschätzten Anforderungen betrachtet werden muss. Gerade am Anfang, bei der ersten Schätzung aller Elemente des Product Backlogs, sollte die Schätzung möglichst leichtgewichtig und schnell gehalten werden. Andernfalls wird zu viel Zeit auf Funktionen verschwendet, die hinterher eventuell gar nicht umgesetzt werden.

Idealtage hingegen fördern eine präzise Schätzung. Auch wenn theoretisch eine exponentiell steigende Wertemenge, wie bei der Verwendung abstrakter Größen, benutzt werden kann, so stellen Idealtage durch den verbleibenden Zeitbezug eine präzisere und damit aufwändigere Schätzung dar.

Story Points gleichen unterschiedliche Skill-Level aus

Das große Problem von Idealtagen ist, dass sie von Teammitglied zu Teammitglied unterschiedlich sind. Ein erfahrener Entwickler mag eine Anforderung auf drei Idealtage schätzen, während ein nicht so erfahrener Kollege vielleicht für die gleiche Anforderung fünf Tage veranschlagen würde.

Eine direkte Übertragbarkeit der Schätzung auf einen anderen Mitarbeiter ist also nicht gegeben. Leider setzt nicht immer, und in Agenturprojekten sogar recht selten, der Mitarbeiter, der die Schätzung initial erstellt hat, die Anforderung im Projektverlauf auch selber um.

Story Points sind als völlig abstrakte Größen frei von diesem Problem. Eine Anforderung bleibt doppelt so groß wie eine andere Anforderung, unabhängig davon, welcher Entwickler sie letzten Endes umsetzt. Das ein erfahrener Entwickler die Aufgabe schneller bewältigt schlägt sich dann in der Velocity, also der Entwicklungsgeschwindigkeit, nieder. Diese gleicht alle Unterschiede in der Erfahrung und dem Wissen der Mitarbeiter aus. Allein die gemeinsame Teamleistung zählt und gibt die nötige Messgröße für die Planung an.

Schätzungen in Story Points sind nachhaltiger

Ein weiteres Problem von Idealtagen ist die zeitliche Begrenztheit. Bei einem neuen System, vielleicht sogar mit einer neuen Programmiersprache, hat das Team noch wenige Erfahrungen gesammelt und schätzt eine einfache Anforderung vielleicht auf 5 Idealtage ein. Gehen wir davon aus, dass das Team in einer Iteration 5 Idealtage bewältigen kann, wird das Feature also in einer Iteration abgeschlossen. Mit zunehmender Erfahrung würde das gleiche Team die gleiche Anforderung aber vielleicht mit nur einem Idealtag bewerten. Bei gleichbleibender Velocity könnte die gleiche Anforderung also auf einmal fünfmal schneller umgesetzt werden.

Schätzungen in Story Points sind hier nachhaltiger. Die Relation zwischen verschiedenen Anforderungen bleibt gleich, lediglich über die Velocity werden zunehmende Erfahrungen mit Bibliotheken, der Programmiersprache oder benutzten Tools eingerechnet. Ändern sich die Details zu einer Anforderung, müssen bei beiden Methoden die Schätzungen angepasst werden. Jedoch sind nur bei den Idealtagen die steigenden Erfahrungen des Teams zu berücksichtigen.

Story Points sind eine reine Schätzung der Größe

Beide Ansätze trennen die Größe einer Anforderung von der zu erwartenden Umsetzungsdauer. Bei Idealtagen ist die Verbindung zur Zeitkomponente aber wesentlich stärker gegeben. In der Kommunikation ist dies nach wie vor ein Problem, da der Kunde oder auch der Projektleiter weiterhin Annahmen über den Fertigstellungstermin anhand der Schätzung in Idealtagen machen.

Story Points lassen solche Überlegungen gar nicht zu und fördern zudem noch stärker ein intuitives und schnelles Einschätzen.

Idealtage sind zuerst einfacher zu schätzen

Für viele Entwicklungsteams fühlt sich die Einschätzung von Product Backlog Elementen in Idealtagen zunächst einfacher und gewohnter an. Sie sind es gewohnt Schätzungen in Tagen abzugeben und so liegt die Verwendung von Idealtagen nahe.

Am Anfang ist die richtige Nutzung von Story Points auch sicher nicht sehr vertrauenserweckend und man muss sich erst auf diese Methode einlassen. Sehr bald, meist nach wenigen Schätzungen, hat sich das Team aber bereits an den Prozess gewöhnt und ist in der Lage sehr schnell und intuitiv zu schätzen.

Idealtage sind einfacher zu erklären, besonders dem Kunden

Als wichtigsten Vorteil der Idealtage sehe ich das einfache Verständnis dieser Methodik an. Es ist sofort einleuchtend und auch von fachfremden Stakeholdern intuitiv zu begreifen. Der Overhead, der die Diskrepanz zwischen Idealtag und einem Entwicklungstag in der Realität ausmacht ist jedem sofort verständlich.

Story Points sind dagegen sehr schwierig zu erklären und erfordern ein grundlegendes Verständnis der zugrunde liegenden Konzepte wie Velocity oder der Planung mit entkoppelten Werten für Größe und Dauer.

Leave A Reply

Navigate