Story Points, was macht Sie so einzigartig sinnvoll?

Mein Blickwinkel auf das Schätzen mit Story Points ist ein besonderer. Denn ich Weiß: Das Missverständnis ist in der Kommunikation der Regelfall.

 

Oder wie ein guter Freund zuletzt sagte: Die Sprache ist die Quelle der Missverständnisse!

 

In Softwareprojekten sind Missverständnisse sehr teuer. Doch leider versuchen wir zu oft diese nur mithilfe von noch mehr Sprache zu lösen. Eine Story Point Estimation ist eines der wirksamsten Mittel gegen Missverständnisse. Und das ohne Nebenwirkungen. Es gibt viele gute Gründe Product Backlog Items in Story Points zu schätzen. Ich möchte alle mir bekannten Vorteile hier darlegen oder nach und nach auf die entsprechenden Blogartikel verlinken. Story Points können so Ihr größter Hebel zur Verbesserung Ihrer Projektarbeit werden.

 

– Michael Nauditt, Geschäftsführer der moguru GmbH

Story Points – einvernehmlich unterschiedlicher Meinung sein

Ich möchte Ihnen das Konzept von Story Points gerne am Beispiel eines Trailruns erläutern. Stellen Sie sich vor, dass ich als kräftiger, normal sportlicher Mann mit über 100 kg Körpergewicht einen Trailrun mit einem 80 kg Trailrun Experten angehen möchte. Wir wählen gemeinsam eine Strecke aus, die uns beiden bekannt ist. Wir beginnen darüber zu diskutieren, wie lange wir für diese Strecke brauchen. Ich sage „30 Minuten“ – „Nein 15“ entgegnet mein Partner. So geht es weiter „30“ – „Nein, 15“ – „Nein, 30“ – „15“ usw.

Wir besprechen die Strecke und sehen, dass wir das gleiche Bild von der Länge (vier Kilometer), der Schwierigkeit (400 Höhenmeter) und den Hindernissen (nur ein kleiner Bach) haben. Das beruhigt die Diskussion. Wir einigen uns unsere nächsten Trailrun Strecken nun mit dieser Strecke zu vergleichen. Wir legen fest: Dies ist unsere sogenannte „Hausstrecke“ und Ausgangspunkt für ein Punktesystem, wobei diese Strecke für einen Punkt steht.

Alsbald steht unser nächster Ausflug an. Wir schauen auf die Karte und planen den ersten Streckenabschnitt. Wir vergleichen die geplante Strecke mit unserer Hausstrecke. Ich sage: Die neue Strecke ist dreimal „so viel Aufwand“ (also drei Punkte) wie unsere Hausstrecke, obwohl Sie nur ca. neun Kilometer lang ist. Dafür gibt es aber größere bekannte Hindernisse. Mein Partner schätzt dies genauso ein. Wir wissen, ich benötige viel länger für die Strecke als er. Da wir aufgrund der Punkte ja aber unsere gemeinsame Referenz haben, können wir uns einigen.

Von Laufpartnern und Trailruns...

Die Planung für den nächsten Streckenabschnitt beginnt. Ich schätze die Strecke wieder auf drei Punkte. Mein Trailrun Partner jedoch auf 8. Wir wissen nun, dass wir trotz einer geeichten Basis völlig unterschiedlicher Meinung über die Strecke sind - wir sind einvernehmlich unterschiedlicher Meinung.

Wir diskutieren die Strecke und es stellt sich raus: Mein Partner kennt die Strecke. Er meint, der Unterboden ist sehr unsicher. Des weiteren geht es teilweise sehr steil aufwärts und es gibt eine Schlucht zu umlaufen. Außerdem ist die eingezeichnete Brücke im letzten Winter eingestürzt.

Wir können also durch den Umweg über das Vergleichen mit unserer Hausstrecke und jeder neuen geschätzten Strecke herausfinden, was wir an den Strecken möglicherweise unterschiedlich sehen. Dadurch können wir teure – ja sogar lebensgefährliche – Missverständnisse aufdecken. So können wir die Aufgaben und Herausforderungen des jeweiligen Abschnittes gut einschätzen.

Die Grundidee hinter den Story Points

Story Points erfüllen den gleichen Zweck. Stellen Sie sich anstelle eines schnellen oder langsamen Läufers zwei Entwickler mit unterschiedlicher Produktivität vor. Sie erlauben Entwicklern mit unterschiedlichen Skills und Erfahrungen sich auf die „Größe“ von Aufgaben (Backlog Items) zu einigen. Und was noch viel wichtiger ist: Herauszufinden, wo es unterschiedliche Einschätzungen über die Aufgabe bzw. deren Herausforderung gibt!

Wie die Läufer vergeben die beiden Programmierer für eine, den beiden bekannte, Aufgabe drei Story Points. Für zwei weitere Ihnen bekannte Aufgaben einen bzw. fünf Story Points. 

Bei der drei Punkte Story mag der schnelle Entwickler denken, dass er ca. einen Tag benötigt. Der langsamere von beiden denkt an zwei Tage Aufwand. Doch durch das Einigen auf Story Points können die Entwickler nun dennoch, wie die Läufer, schnell feststellen, wo Sie Entwicklungsaufgaben ähnlich und wo sehr unterschiedlich bewerten.

Bei einer neuen Aufgabe wird der schnellere Entwickler denken: „Ich benötige ungefähr drei Tage, also ca. neun Story Points.“ Der langsame geht von 6 Tagen aus, kommt aber auf das gleiche Ergebnis von neun Story Points.

Wenn nun die Einschätzungen voneinander abweichen, wissen beide: Sie sehen die Aufgabe unterschiedlich. Anschließend können sie durch Diskussion das Missverständnis aufdecken und die Ausführung der Aufgabe gemeinsam korrekt planen bzw. mit Ihnen offene Fragen klären.

Story Point Estimation: Planning Poker

Planning Poker ist eine Technik zur „Größenabschätzung“ von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning Anwendung findet.

Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Das Planning Poker führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.

Bereits nach ca. 4 - 5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.

Planning Poker

Scrum in Ihrem Unternehmen

Sie benötigen Unterstützung für einzelne Teams oder Hilfe bei der Agilen Transformation Ihres Unternehmens?

Unsere Certified Scrum Masters und Scrum Coaches helfen Ihnen, Schlagworte wie 'Agil' und 'Scrum' erfolgreich mit Leben zu füllen.

Nutzen Sie jetzt unser kostenfreies Micro Consulting.

Zum Micro Consulting

Scrum im Detail

Scrum - Das agile Vorgehensmodell

Lernen Sie das agile Vorgehensmodell Scrum im Detail kennen.

Jetzt ansehen!