Sollten Sie in Stunden oder Story-Punkten schätzen?
In fast jedem agilen Team, mit dem ich in den letzten 15 Jahren zusammengearbeitet habe, stellte sich die Frage: Sollten wir die Arbeit in Stunden oder Story-Punkte schätzen?
Hier werden wir die Vor- und Nachteile betrachten und daraus schließen, dass es zwar nur wenige Vorteile von Story-Punkten gegenüber Stunden gibt, es jedoch viele Vorteile von Stunden gegenüber Story-Punkten gibt und dass wir daher fast immer Stunden verwenden sollten.
1 Was sind Story-Punkte?
Story-Punkte sind eine Maßeinheit, um eine Schätzung des Gesamtaufwandes auszudrücken, der erforderlich ist, um ein Feature oder eine andere Arbeit vollständig zu implementieren. Wenn wir mit Story-Punkten schätzen, weisen wir jeder Aufgabe einen Punktwert zu.
Die häufigsten Werte für Story-Punkte sind:
● 0,5: Mini-Aufgabe
● 1: sehr kleine Aufgabe
● 2: kleine Aufgabe
● 3: eher kleine Aufgabe
● 5: normale Aufgabe
● 8: ziemlich große Aufgabe
● 13 große Aufgabe
● 20: sehr große Aufgabe
● 40: extrem große Aufgabe
● 100 : Riesenaufgabe
Es ist wichtig zu beachten, dass nicht gemessen wird, wie komplex oder schwierig eine Aufgabe ist, sondern nur wie viel Zeitaufwand erforderlich ist. Zum Beispiel kann eine Gehirnoperation sowie auch das Aufkleben von 5000 Briefmarken auf Briefen beides 3 Stunden dauern. Zwar ist eine Gehirnoperation viel schwieriger als das Anbringen von Briefmarken auf einem Brief, dies hat jedoch keinen Einfluss auf die Story-Punkte. Beide Aufgaben hätten die gleichen Story-Punkte. Das zeigt, dass Story-Punkte wirklich ein Maß für die Zeit sind, genau wie Tage, Stunden und Minuten.
Trotzdem bevorzugen viele agile Teams die Schätzung in Story-Punkten anstatt in Stunden. Die Gründe dafür werden wir unten diskutieren.
2 Vorteile der Schätzung in Story-Punkten gegenüber der Schätzung in Stunden
Hier zeigen wir die Vorteile der Schätzung in Story-Punkten gegenüber der Schätzung in Stunden.
2.1 Story-Punkte standardisieren verschiedene Teammitglieder
Das Hauptargument für die Verwendung von Story-Punkte an Stelle von Stunden ist, dass sie nicht von den Fähigkeiten und der Geschwindigkeit der Softwareentwickler abhängen. Story-Punkte sind gleich, egal ob ein Junior-Entwickler oder ein Senior-Entwickler an einer Aufgabe arbeitet. Beispielsweise kann eine Funktionalität für einen Junior-Entwickler 6 Stunden dauern, während der Senior-Entwickler 2 Stunden benötigt. Wenn wir also stündliche Schätzungen vornehmen würden, müssten wir zuerst wissen, wer für die Aufgabe verantwortlich ist. Für Story-Punkte können wir diesem Feature jedoch 3 Story-Punkte zuweisen, da wir wissen, dass die erwartete Zeit je nach Entwickler unterschiedlich sein wird.
Dies scheint ein klarer Vorteil von Story-Punkten gegenüber Stunden zu sein. Bei näherer Betrachtung sehen wir jedoch, dass der gleiche Vorteil für Stundenschätzungen erzielt werden kann, wenn ein “Standard” -Entwickler angenommen wird. Wenn im obigen Beispiel eine Aufgaben von einem Senior-Entwickler in 2 Stunden und einem Junior-Entwickler in 6 Stunden entwickelt wird und wir einen Story-Punkt von 4 annehmen, können wir auch davon ausgehen, dass ein Standardentwickler 4 Stunden benötigt.
Wenn wir also bei der Stundenschätzung einen Standartentwickler annehmen, gibt es keinen Vorteil mehr für Story-Punkte gegenüber Stunden.
2.2 Story-Punkte sind agil
Einige Befürworter von Story-Punkte sagen, dass sie besser sind, da sie agil sind. Aber was ist agil an ihnen? Nur, dass Story-Punkte von vielen agilen Praktizierenden verwendet werden. Aber wir könnten eine agile Methodik implementieren, ohne die Arbeit in Story-Punkten, sondern in Stunden zu messen. Wie wir weiter unten sehen werden, unterstützen Stunden die Transparenz und somit einen wichtigen Teil der Beweglichkeit, während Story-Punkte die Intransparenz unterstützen.
2.3 Story-Punkte ermöglichen Planungspoker
Einige Befürworter von Story-Punkte sagen, dass sie für Planungspoker benötigt werden. Hierbei handelt es sich um eine Schätzübung, bei der das gesamte Team die Arbeit einzeln schätzt und dann ihre Schätzungen vergleicht.
Der Planungspoker kann jedoch mit stündlichen Schätzungen genauso erfolgen wie mit Story-Punkten. Daher ist dies kein Vorteil von Story-Punkte gegenüber stündlichen Schätzungen.
2.4 Story-Punkte sind zuverlässiger
Einige Befürworter von Story-Punkten sagen, dass sie eher richtig sind als Schätzungen pro Stunde. Ob das stimmt, hängt sehr davon ab, was wir als richtig verstehen. Für Story-Punkte werden Schätzungen oft als richtig bezeichnet, wenn eine als 13 Story-Punkte geschätzte Aufgabe tatsächlich größer war als eine als 8 Story-Punkte geschätzte Aufgabe. Für Stundenschätzungen hingegen wird es nicht als ausreichend angesehen, wenn eine auf 13 Stunden geschätzte Aufgabe länger dauert als die auf 8 Stunden geschätzte Aufgabe, sondern es wird gefragt, ob die Aufgabe wirklich genau die Stunden benötigt hat. Dies sind also zwei verschiedene Standards. Wenn wir jedoch “richtig¨ fuer Stundenschätzungen genauso definieren; also das die relative Größe der Aufgaben korrekt geschätzt wurde, dann gibt es keinen Vorteil von Story-Punkten gegenüber Stundenschätzungen.
2.5 Stunden können nicht genau geschätzt werden
Befürworter von Story-Punkte sagen, dass Schätzungen in Stunden nicht genau durchgeführt werden können und dass die Stunden aus vielen verschiedenen Gründen variieren können.
Das ist wahr! Aber warum ist das ein Problem der Schätzungen in Stunden? Niemand erwartet, dass die Stundenschätzungen genau sind, so wie die Schätzungen der Story-Punkte auch nicht genau sind.
Wenn die Erwartung an die Schätzungen in Stunden und Story-Punkten gleich ist, was bedeutet, dass die Leute verstehen, dass sie nicht präzise sein können, gibt es keinen Unterschied zwischen den beiden.
2.6 Story-Punkte ermöglichen eine schnellere Schätzung
Befürworter von Story-Punkte sagen, dass Schätzungen in Story-Punkte schneller sind und sie auf die Erfahrung von Teams verweisen, die die Schätzzeit beim Wechsel von Stunden zu Story-Punkte verkürzt haben.
Obwohl wir diese Erfahrungen nicht bezweifeln, ist der Unterschied auf die Tatsache zurückzuführen, dass Teams, die in Stunden schätzen, häufig gebeten werden, so genau wie möglich zu sein, während Teams, die in Story-Punkten schätzen, nur eine voreingestellte Story-Punkt Nummer zuweisen müssen. Eine langsamere Schätzung für Stunden hat also mit der erwarteten Genauigkeit zu tun. Wenn Teams gebeten werden, die Stunden nur sehr grob zu schätzen, beispielsweise nur aus voreingestellten Werten auszuwählen (z. B. 1, 2, 3, 5, 10, 20, 40 und 100), gibt es keinen Grund fuer Schätzungen länger zu dauern.
2.7 Story-Punkte begrenzen den Zeitdruck des Managements
Bisher haben wir gesehen, dass keines der Argumente für Story-Punkte über Stunden zutrifft, da die gleichen Vorteile mit stündlichen Schätzungen erzielt werden können:
● die auf einem Standardentwickler basieren,
● von denen keine hohe Präzision abverlangt wird, und
● die auf grobe Weise erstellt werden.
Es gibt jedoch einen weiteren Vorteil von Story-Punkten, der nicht allgemein erwähnt wird: Story-Punkte sind für das Management weniger leicht zu kontrollieren. Das heißt, wenn ein Entwickler eine Aufgabe auf 5 Story-Punkte schätzt und dann 50% mehr als erwartet benötigt, ist dies für andere schwer zu bemerken. Wenn aber der Entwickler eine Aufgabe auf 5 Stunden schätzt und dann 50% mehr, also 7,5 Stunden, benötigt, ist dies für alle sichtbar.
In meiner Erfahrung mit der Entscheidung zwischen Story Point und stündlichen Schätzungen mit Entwicklern in den letzten 15 Jahren habe ich gesehen, dass dies tatsächlich der Hauptgrund für Story-Punkte ist, obwohl Entwickler dies nicht explizit erwähnen. Dies wird in offenen Diskussionen deutlich, wenn Entwickler die folgenden Bedenken äußern: ¨Ich kann den Aufwand für viele Funktionen nicht genau abschätzen, und mir ist bewusst, dass ich in der Vergangenheit oft in eine Richtung geschätzt habe und es dann dreimal so viel Zeit gedauert hat. Ich möchte nicht, dass Sie mir später sagen, dass ich schuld bin, weil die Dinge länger gedauert haben. “
Story-Punkte haben also den Vorteil für Entwickler in einer Umgebung, in der Kunden oder das Management sie unter Druck setzen, sich an den Zeitpunkt ihrer ursprünglichen Zeitschätzung zu halten. In wirklich agilen Organisationen sollten die Entwickler diesen Druck jedoch nicht spüren.
Zusammenfassend lässt sich sagen, dass Story-Punkte unter den folgenden Umständen keine Vorteile bieten:
● Zeitschätzungen:
○ die auf einem Standardentwickler basieren,
○ von denen keine hohe Präzision abverlangt wird, und
○ die auf grobe Weise erstellt werden.
● Kein Druck des Managements, Zeitschätzungen einzuhalten.
3 Vorteile der Schätzung in Stunden gegenüber der Schätzung in Story-Punkten
Wenn Story Punkte keine Vorteile gegenüber stündlichen Schätzungen bieten, müssen wir prüfen, ob stündliche Schätzungen gegenüber Story-Punkten Vorteile haben.
Tatsächlich gibt es mehrere Vorteile von stündlichen Schätzungen gegenüber Story-Punkt-Schätzungen.
3.1 Stunden erlauben es zu wissen, wie viel Zeit Aufgaben brauchen
Wenn wir Story Points verwenden, um zu planen, wie viel Arbeit wir in einem Sprint übernehmen können, müssen wir Story Points mit der Teamgeschwindigkeit vergleichen. Dieser Vorgang läuft wie folgt ab:
● Bestimmen Sie, wie viele Story-Punkte ein Team im Sprint erreichen kann (Teamgeschwindigkeit).
● Addieren Sie die Story-Punkte und vergleichen Sie sie mit der Teamgeschwindigkeit, um festzustellen, ob die Arbeitsbelastung für den Sprint realistisch ist.
Diese Berechnung dauert einige Zeit, während klar sein sollte, wie viele Stunden das Team arbeiten wird und die zulässige Sprintarbeitslast leicht zu erkennen ist.
3.2 Stunden haben für alle die gleiche Bedeutung
Bei der Schätzung mit Story-Punkten können Teams entscheiden, dass eine 100-Story-Point-Aufgabe die 20-fache Arbeitsbelastung einer 5-Story-Point-Aufgabe haben soll, oder sie können sogar festlegen, dass ein Story-Punkt einer Stunde entspricht. Nur wenn das Team eine solche Definition festlegt, können die Teammitglieder eine klare Kommunikation über Story-Punkte haben. Wenn diese Definitionen jedoch fehlen, kann ein Entwickler davon ausgehen, dass ein Story-Punkt ungefähr 3 Stunden entspricht, während ein anderer der Meinung ist, dass dies ungefähr 5 Stunden entspricht. Daraus resultierend werden Sie falsch kommunizieren, wenn sie über Story-Punkte sprechen.
Das Problem wird bei der Kommunikation zwischen verschiedenen Teams noch größer, da jedes Team möglicherweise anders definiert, wie viel ein Story Point in Bezug auf die Zeit bedeutet.
Stunden haben immer für alle die gleiche Definition, so dass es keine Missverständnisse gibt.
3.3 Stunden sind für das Management und andere externe Stakeholder verständlich und führen somit zu mehr Transparenz
Ein wesentlicher Vorteil von Stundenschätzungen besteht darin, dass jeder, auch wenn er nicht mit Scrum und der Definition von Story-Punkte vertraut ist, ihre Bedeutung verstehen kann.
Dies kann natürlich ein Nachteil sein, wenn Sie Entwickler sind und nicht möchten, dass das Management Sie in Bezug auf die Zeit der Softwareentwicklung unter Druck setzt. Der Geist der Agilität ist jedoch Transparenz und Zusammenarbeit zwischen Kunde und Entwickler sowie zwischen Management und Entwickler. Dies bedeutet, dass von der Management und dem Kunden erwartet wird, dass sie für den Entwickler offen und transparent sind, aber auch, dass der Entwickler nichts vor dem Kunden oder dem Management zu verbergen hat.
Die Schätzung in Stunden macht die Schätzung für alle verständlich und trägt somit zur Transparenz bei.
3.4 Stunden machen offensichtliche Schätzfehler und Verzögerungen
Mit stündlichen Schätzungen wird es viel einfacher, Abweichungen in der tatsächlichen Entwicklungszeit von den ursprünglichen Schätzungen zu erkennen. Softwareentwickler, die Transparenz nicht schätzen, halten dies möglicherweise für eine schlechte Sache, aber für eine agile Organisation ist dies eine großartige Sache.
Eine agile Organisation möchte kontinuierlich Ergebnisse messen, sich selbst reflektieren und verbessern, und Offenheit in Bezug auf Schätzfehler und Verzögerungen hilft dabei.
3.5 Stunden ermöglichen es, den Fortschritt zu reflektieren
Das agile Team und das Management möchten den Fortschritt des Projekts kontinuierlich verfolgen. Dieser Fortschritt muss nicht nur an abgeschlossenen Aufgaben gemessen werden, sondern auch an laufenden Aufgaben. Nehmen wir zum Beispiel an, wir haben 10 Features für einen Sprint geplant und in der Mitte des Sprints ist nur 1 Feature fertig, aber bereits 8 Features sind zu 90% fertig. In diesem Fall ist klar, dass wir, um eine realistische Bewertung des Fortschritts zu erhalten, die laufenden Aufgaben berücksichtigen müssen. Das heißt, wir müssen die gesamten Story-Punkte der laufenden Aufgaben in den Teil, der erledigt wurde, und den Teil, der noch übrig ist, aufteilen. Dies ist jedoch schwieriger, wenn Story-Punkte anstelle von Stunden verwendet werden.
Dies ist insbesondere dann der Fall, wenn sich bei der Arbeit an einem Feature herausstellt, dass die ursprüngliche Story-Point-Schätzung falsch war. Was sollte ein Entwickler beispielsweise tun, wenn er feststellt, dass eine 40-Story-Point-Aufgabe nur eine Stunde gedauert hat, bis sie zu 90% abgeschlossen ist, oder wenn er sieht, dass eine Aufgabe, deren Schätzung auf 2 Story-Punkte geschätzt wurde, schon 100 Stunden gedauert hat und nur zu 30% abgeschlossen ist. Passt er den ursprünglichen und den verbleibenden Story Point an? Und wie macht er das?
Bei einer stündlichen Schätzung sind diese Anpassungen weitaus einfacher, da der Entwickler weiß, wie viele Stunden er bereits an der Aufgabe gearbeitet hat.
3.6 Stundenschätzungen werden mit Zeiterfassung und stündlicher Abrechnung kombiniert
Ein weiterer Vorteil von Stundenschätzungen besteht darin, dass sie mit Zeiterfassung und Zeitabrechnungen kombiniert werden. Die Zeiterfassung ist für viele Organisationen wie Anwälte oder Entwickler erforderlich, da diese oft stündlich abrechnen. Das Schöne ist, dass wir das gleiche System verwenden können, um den Aufwand zu planen und ihn dann zu verfolgen, während wir daran arbeiten, und ihn zur Abrechnung zu verwenden, nachdem wir die Aufgabe abgeschlossen haben. Dies ist möglich, weil wir beim Kunden die Stunden, aber keine Story-Punkte abrechnen können.
4 Stunden-Schätzung ist besser als Story-Punkt-Schätzung
Wir haben gesehen, dass es keine Vorteile der Story-Punkt-Schätzung über der Stunden-Schätzung gibt, zumindest unter folgenden Umständen:
● Zeitschätzungen:
○ die auf einem Standardentwickler basieren,
○ von denen keine hohe Präzision abverlangt wird, und
○ die auf grobe Weise erstellt werden.
● Kein Druck des Managements, Zeitschätzungen einzuhalten.
Auf der anderen Seite gibt es viele Vorteile von stündlichen Schätzungen gegenüber der Schätzung von Story-Punkten. Aus diesem Grund sollte niemand Story-Punkte verwenden. Und zum Wohle von Produktivität und Agilität sollten wir alle versuchen, Story-Punkte aus agilen Frameworks zu entfernen.
Aus diesen Gründen verwenden wir keine Story-Punkte mehr intern, sondern schätzen die Zeit immer in Stunden. Asusedrem empfehlen wir den nutzern unserer Fokus- und Produktivitätssoftware Workiamo in Stunden zu schätzen. Wir geben den Menschen jedoch die Flexibilität, in Story-Punkte zu schätzen, wenn sie dies bevorzugen.
Da Sie dieses Buch lesen, können Sie lebenslang kostenlos auf unsere Produktivitätssoftware zugreifen! Dazu müssen Sie sich unter www.workiamo.com registrieren, indem Sie den folgenden Code eingeben: ILOVEWORK
