Warum Story Points besser als Aufwandsschätzungen sind

Story Points sind Aufwandsschätzungen überlegen. Dennoch sind klassische Aufwandsschätzungen in vielen Firmen immer noch Teil des Tagesgeschäfts. In agilen Unternehmen jedoch sind sie verschwunden und wurden durch Komplexitätsschätzungen mit Story Points ersetzt. Dieser Artikel zeigt weshalb es sinnvoll ist Story Points zu schätzen und nicht Aufwände.

Table of Contents

Aufwandsschätzungen Fördern Angst

Jeder kennt klassische Aufwandsschätzungen. Das Management fordert die Entwicklungsorganisation auf eine Prognose für die Dauer oder den Aufwand für die Umsetzung einer Anforderung abzugeben. Diese Schätzung dient dann als Grundlage für die kommerzielle Bewertung der Anforderung. Gegebenenfalls ist sie Basis für die Erstellung von Angeboten an Kunden. So weit so gut, wenn die genannten Schätzungen denn korrekt sind. Es gibt aber zwei Haken an der Sache

Einerseits werden klassische Aufwandsschätzungen von klassischen Managern nicht als Schätzungen betrachtet. Sie werden als eine Zusage gesehen die entsprechende Aufgabe auch verlässlich in der genannten Zeit abzuschließen. Dies führt zu Angst bei den Entwicklern die Schätzung zu optimistisch abzugeben. In der Folge integrieren die Entwickler Puffer in ihre Schätzungen. Das führt wiederum dazu, dass die Bearbeitungszeit dann tatsächlich steigt.

Wenn ein Entwickler sechs Stunden Zeit für eine Aufgabe hat, dann wird er diese erfahrungsgemäß auch aufbrauchen. Unabhängig davon, ob seine ursprüngliche Schätzung bei vier Stunden lag oder nicht. Nun fügen entlang der Bewertungskette viele Entwickler und Manager Puffer zur Schätzung hinzu. Diese bläst sich immer weiter auf und wird im schlimmsten Fall sogar unwirtschaftlich.

Anderseits sind Aufwandsschätzungen auch niemals korrekt, denn niemand kann die Dauer einer Aufgabe exakt schätzen. Dies führt dazu, dass Entwickler bei jeder Schätzung ein negatives Erfolgserlebnis erfahren. Die abgegebene Schätzung ist schon bei ihrer Abgabe darauf programmiert nicht eingehalten zu werden. Dieser Effekt verstärkt sich je weiter die Umsetzung einer Anforderung in der Zukunft liegt.

Es ist beinahe unmöglich sinnvolle Schätzungen für Anforderungen abzugeben welche noch nicht im Detail diskutiert und verfeinert wurden. Die klassischen Schätzmethoden lassen aber keinen Spielraum für Risikobewertung und die Einbeziehung von Unsicherheiten, Unklarheiten oder potentiellen Stolpersteinen. Demnach weichen sie gerade für große Probleme massiv von der späteren, tatsächlichen Bearbeitungszeit ab.

Story Points Sind Niemals Falsch

Den Unzulänglichkeiten der klassischen Aufwandsschätzung wird in der agilen Produktentwicklung durch die Verwendung von Story Points begegnet. Story Points sind ein Werkzeug welches die Komplexität von Anforderungen abbildet und nicht den Umsetzungsaufwand. Hierbei werden nicht nur Risiken und Unwägbarkeiten berücksichtigt. Sie folgen auch dem Kegel der Unsicherheit, und geben somit einen Anhaltspunkt für den Reifegrad der bewerteten Anforderungen.

Die Story Points, und somit die Komplexitätsgrade, werden vom Team aber nicht frei gewählt oder erfunden. Sie ergeben sich aus den Zahlen der Fibonacci-Folge. Diese bilden auch in der Natur natürliche Wachstumsfunktionen ab. Damit sind sie gut geeignet um die Größe von Problemen zu bewerten. Denn Menschen kennen diese Größenordnungen ganz intuitiv aus der Natur und ihrem Alltag.

Die Fibonacci-Folge als Maß für Komplexität

Im Planning Poker werden üblicherweise die Zahlen 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100 für die Schätzung der Komplexität verwendet. Wie sich zeigt weichen die Zahlen ab der 20 von der Fibonacci-Folge ab. Dies ist jedoch unerheblich. Durch das exponentielle Wachstum der Folge werden die Risiken und die wachsende Unsicherheit bei großen Problemen abgebildet.

Ob ein Problem 20 Punkte oder 21 Punkte groß ist, ist völlig unerheblich. In Realität könnte es auch 19 Punkte groß sein, oder 24, oder 17, oder 22. Dies ist aber unklar und unerheblich, da das Problem noch viel zu groß ist um sinnvoll überblickt werden zu können. Demnach muss es im Refinement weiter zerlegt und anschließend erneut geschätzt werden.

Die Geschwindigkeit (Velocity) eines Teams wird nun also nicht in erzeugtem Aufwand, sondern in abgearbeiteten Story Points gemessen. Die einzige Voraussetzung ist die, dass ein Team die Story Points konsistent schätzt. Hierzu kann es sich Referenzprobleme verschiedener Größenordnungen definieren und diese immer wieder als Maßstab verwenden. Als empirische Basis für die Planung eines Sprints wird dann die gleitende Durchschnittsgeschwindigkeit der letzten Sprints verwendet. Dies macht es unmöglich Puffer einzubauen. Wenn alle Anforderungen konsistent geschätzt werden und sich die Planung an empirischen Daten orientiert gibt es keinen künstlichen Puffer.

Das Gute an der Schätzung von Story Points ist weiterhin, dass diese nie falsch geschätzt werden können. Dies macht einen großen Unterschied in Bezug auf die emotionale Stimmung eines Entwicklungsteams. Weiterhin werden Puffer und Angst reduziert, was auch einen enorm positiven Einfluss auf die Arbeit des Teams hat.

Der Finanzielle Wert Eines Story Points

Allerdings stellt sich nun die Frage wie man zu einer finanziellen Bewertung einer Anforderung kommen kann. Geschätzte Aufwände können mit einem Stundensatz multipliziert und so in eine kommerzielle Aussage umgewandelt werden. Wie ergibt sich eine solche Bewertung bei der Schätzung mit Story Points?

Diese Frage lässt sich leicht beantworten. Story Points können natürlich in tatsächliche Aufwände zurück gerechnet werden. Dies geschieht jedoch auf Basis von empirischen Aussagen über die Performance des Teams. Gehen wir von einem Team aus, welches eine Geschwindigkeit von 50 Story Points in einem 2-wöchigen Sprint hat. Demnach schafft dieses Team 100 Punkte pro Monat. Ein Story Point kostet in diesem Team also 1% der monatlichen Teamkosten. Auf dieser Grundlage kann jede Schätzung des Teams in eine finanzielle Bewertung der entsprechenden Anforderung überführt werden.

Man kann nun auf die Idee kommen verschiedene Teams miteinander zu vergleichen und diese auf ihre Kosteneffizienz bezüglich eines gelieferten Story Points zu bewerten. Dies ist eine schlechte, um nicht zu sagen ganz, ganz … ganz schlechte Idee. Erstens ist die Größe eines Story Point zwischen Teams nicht vergleichbar. Jedes Team schätzt anders und hat andere Vorstellungen von Komplexität. Zweitens geht es bei agilen Methoden darum den Kundennutzen und den Wert des gelieferten Produktes zu erhöhen und zu optimieren. Aus den Kosten eines Story Point lassen sich darauf aber keinerlei Rückschlüsse ziehen.

Abschließende Gedanken

Abschließend zeigt sich also, dass die Schätzung von Story Points deutlich sinnvoller ist als die klassischen Aufwandsschätzungen. Sie berücksichtigen Risiken und Unschärfe von großen Problemen. Sie demotivieren nicht durch negative Erfolgserlebnisse. Weiterhin ist es (fast) unmöglich künstliche Puffer einzubauen. Damit erhöhen Story Points die Transparenz in der Entwicklung. Kurz gesagt, die Schätzungen von Komplexitäten mit Story Points sind Aufwandsschätzungen überlegen.

Zurück zum Blog

Von der Theorie in die Praxis? Besuchen Sie agile Trainings bei AgileSkills!

1 von 4
  • Lead Time und Cycle Time in Kanban Systemen

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

  • Throughput und Delivery Rate in Kanban Systemen

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

  • Ein kurzer Leitfaden über Objectives und Key Results

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

  • A Beginners Guide to Kanban Metrics

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

1 von 4
Dr.-Ing. Stefan Döbrich

Fragen und Antworten

Sie haben offene Fragen zu Agilität?

Sie haben noch offene Fragen zum Artikel, zu agilen Methoden, oder Probleme bei der Umsetzung von Agilität in der Praxis?

Schreiben Sie mir, und wir vereinbaren ein Erstgespräch! Wir machen uns gemeinsam auf den Weg. Versprochen!

Jetzt Kontakt Aufnehmen