Story-Points: Normierung der Skala und Planung

Geschrieben von Sven Wiegand am 20. Oktober 2015 in Projektmethodik
Geschätzte Lesedauer: 6 Minuten

Im letzten Artikel haben wir uns angeschaut, was Story-Points sind und wie sie von der Idee her funktionieren. In diesem zweiten Artikel der Reihe geht es darum, wie Dein Team zu einer funktionierenden Story-Point-Skala kommt und wie Du Deine Planung auf Basis von Story-Point-Abschätzungen erstellen kannst. Außerdem schauen wir uns drei häufige Probleme aus der Praxis an.

Da Story-Points eine relative Größe darstellen, können sie sich von Team zu Team stark unterscheiden. Resultiert eine 8‑Punkte-Story bei einem Team in einem Aufwand von 2 Personentagen können es bei einem anderen Team 10 oder 20 Personentage sein. Wie definieren wir nun unsere Story-Points, wenn wir bisher in anderen Einheiten abgeschätzt haben und auf Story-Points umstellen wollen?

Normierung der Skala mittels »Estimation Kick-Off«

Ich nenne den Prozess des Einrichtens der Skala »Estimation Kick-Off«. Die Voraussetzung zur Durchführung ist eine repräsentative Anzahl (mindestens ca. 20) von User-Stories. Die Stories müssen zu diesem Zeitpunkt noch nicht »ready« sein – selbst eine Liste von Story-Überschriften genügt bereits. Neben dem Team und dem Scrum-Master muss an dem Meeting auch der Product-Owner teilnehmen, damit er Fragen zu den Stories beantworten kann.

Die Stories müssen in Papierform (zum Beispiel Karteikarten) vorliegen. Das Team sortiert die Stories dann gemäß ihrer Komplexität von der niedrigsten bis zur höchsten Story. Danach beginnt die Cluster-Bildung: Die am wenigsten komplexe Story erhält den Punktewert »1«. Alle weiteren Stories bis exklusive der ersten, die ungefähr doppelt so komplex ist erhalten ebenfalls den Wert »1« – die doppelt so komplexe erhält den Wert »2«. Auf diese Art werden die Cluster weiter gebildet, bis alle Stories den Punktewerten der gewählten Skala (zur Erinnerung: 1, 2, 3, 5, 8, 13, 20, 40, 100) zugewiesen sind.

Et voila: Fertig ist unsere normierte Skala.

Das Schöne daran: Das müsst Ihr nur einmal machen, nämlich dann wenn wir erstmals im Team mit Story-Points arbeiten. Danach wird das Team ein intuitives Gefühl für seine Skala entwickeln und Du wirst Aussagen wie »das ist eine klassische 13er-Story« hören.

Für weitere Abschätzungen werde ich Dir im nächsten Artikel zwei Varianten zur effizienten Durchführung von Abschätzungs-Meetings vorstellen.

Planung mit Story-Points

In den meisten Unternehmen wird vom Product-Owner erwartet, dass er zumindest eine grobe Planung bereitstellt, bevor ein Projekt genehmigt wird. Wie kommen wir nun von den abstrakten Story-Points zu konkreten Werten? Ganz einfach: Durch die Geschwindigkeit unseres Teams.

Wenn Dein Team eine repräsentative Anzahl von Sprints hinter sich hat wird sich eine relativ stabile, mittlere Geschwindigkeit einstellen. Diese Geschwindigkeit wird in Punkten pro Sprint gemessen und setzt somit natürlich konstante Sprint-Längen voraus. In den einzelnen Sprints kann die Geschwindigkeit stark variieren – gerade in den ersten Sprints ist ein Sägezahnmuster im Verlauf der Geschwindigkeit nicht untypisch – aber im Mittel sollte sie sich stabilisieren solange Du keine größeren Anpassungen am Team oder Technologie-Stack vornimmst.

Pendelt sich Dein sechsköpfiges Team also zum Beispiel bei 25 Punkten pro Sprint ein, so hat es eine Geschwindigkeit (»Velocity«) von 25 Punkten/Sprint. Steht nun Dein nächstes Projekt an und Team und Sprint-Länge bleiben gleich, so kannst Du auf Basis der Story-Point-Abschätzungen für Deine Stories die Projektlaufzeit vorhersagen.

Musst Du auch die Kosten (den Aufwand in Personentagen) beziffern, so ist lediglich etwas Rechenarbeit notwendig: Hast Du ein sechsköpfiges Team, das zu 100% an einem Projekt arbeitet und bei zweiwöchigen Sprints im Schnitt 25 Punkte schafft, so kommst Du auf 60 Personentage pro Sprint, was bei 25 Punkten 0,42 Story Points/Personentag entspricht.

Viele Agilisten verteufeln diese Umrechnungen in Personentage, aber in der Realität sind sie nun mal einfach notwendig. Wichtig dabei ist zu bedenken, dass sich die Geschwindigkeit des Teams ändern kann und somit diese Rechnungen eine Planung zu einem bestimmten Zeitpunkt darstellen.

Was machst Du aber nun, wenn Du einen Stapel von Stories hast, die erstmals in Story-Points abgeschätzt wurden, Dein Team noch keine Sprints durchgeführt hat und Du trotzdem Aufwände beziffern musst? Nun ja, Du könntest natürlich nochmal alle Stories in Personentagen schätzen lassen und Dich so beim Team unbeliebt machen. Bei der pragmatischeren und weniger aufwändigen Variante wählst Du (oder das Team) ein paar Referenz-Stories aus, die dann nochmal in Personentagen abgeschätzt werden. Diese Information sollte dann bereits genügen, um auch die anderen Stories in Personen-Tage überführen zu können.

Wichtig: Eine Planung hat immer mit Schätzung und somit mit Ungenauigkeit zu tun. Das schöne ist, dass Du Deine Planung nach jedem Sprint auf Basis der aktuellen Geschwindigkeitsentwicklung Deines Teams mit minimalem Aufwand aktualisieren kannst.

Häufige Probleme in der Praxis

Die folgenden Probleme sind mir in der Praxis bereits begegnet

Die »kaputte« Skala

Am Anfang tut sich das Team schwer die kleinsten und größten Werte der Story-Punkte-Skala zu vergeben. Es könnte ja noch eine Story geben, die noch kleiner oder noch größer ist. Das resultiert dann darin, dass von der ursprünglichen Skala zum Beispiel nur noch die Werte 3, 5, 8 und 13 genutzt werden. Dadurch ist keine große Differenzierung mehr vorhanden und eine Planung wird ungenauer.

Die nicht-lineare Skala

Das Problem geht häufig mit der kaputten Skala einher: Das Team weist aus Sicherheit gerne einen mittleren Wert der eh schon kleinen Skala zu und am Ende hat die Hälfte aller Stories 8 Punkte, egal ob sie groß oder klein sind. Damit ist die Linearität der Skala nicht mehr gegeben und eine sinnvolle Planung nicht mehr möglich.

Das Streben nach exakten Abschätzungen

Manager möchten gerne exakte Abschätzungen von Dir haben, um die Kosten und den Liefertermin exakt voraussagen zu können. Ich verstehe diesen Wunsch, aber er ist nicht leistbar. Das Wort »Schätzung« impliziert schon, dass es sich genau um das – eine Schätzung – handelt. Häufig wird man also gebeten mehr Aufwand für eine genauere Schätzung zu investieren.

Meiner Erfahrung nach bringt selbst ein erheblicher Mehraufwand bei der Abschätzung nur geringfügig bessere Ergebnisse.

Eine beliebte Folgefrage zu einer Grobabschätzung ist dann die nach der Genauigkeit der Abschätzung: »Was denkst Du: Liegt die Abschätzung im Bereich +/-20%?« Nun ja, um das beantworten zu können müsste ich natürlich vorher wissen, wie lange wir nachher tatsächlich brauchen werden. Und wenn ich das wüsste, dann könnte ich auch den exakten Wert benennen…

Meiner Meinung nach sind Feinabschätzungen nichts weiter als Zeitverschwendung. Wenn nicht mal ein Fliesenleger die Kosten für das Fliesen eines neuen Fußbodens auf 10% genau vorhersagen kann (meine Erfahrung), dann kann ich nicht erwarten, dass ein 1.000 Personentage-Projekt exakt abgeschätzt werden kann. Am Ende wird die Umsetzung so lange dauern wie sie halt braucht – daran ändert auch eine genauere Abschätzung nichts.

Fazit

Story-Points bieten eine schöne Alternative zur konventionellen Abschätzung in Personentagen. Die Abstraktion von einem realen Wert und der Vergleich von Komplexitäten erleichtert dem Team die Abschätzung und uns die Anpassung der Planung an die Änderung der Geschwindigkeit des Teams.

Im nächsten Artikel zeige ich Dir, wie Du mit Deinem Team auch eine hohe Anzahl von Stories mit vertretbarem Aufwand abschätzen kannst.

Tags:Backlog, Backlog-Management, Scrum, User-Story

Trackback von deiner Website.

Sven Wiegand

Ich leite seit 2005 Softwareprojekte und führe Entwicklungsteams in mittelständischen Softwareunternehmen. Nach einigen erfolglosen Projekten auf Basis des konventionellen Wasserfallmodells begann ich 2008, Scrum anzuwenden. Seitdem stellte ich mehrere Teams erfolgreich auf agile Methoden um. Auf »Agil Managen« möchte ich meine Erfahrungen aus der Praxis mit Dir teilen.