Story-Points. Worum handelt es sich, was sind die Vorteile und welche Nachteile verbergen sich dahinter?

Lesedauer ca. 13 Minuten

Woher kommen die Story Points?

Die Geschichte der Story-Points ist ein wenig unklar. Ron Jeffries‘ Name fällt oft. Er behauptet, er habe sie entweder „erfunden oder war dabei, als sie erfunden wurden„.

Eines ist jedoch sicher: Sie sind nicht Teil von Scrum (entgegen dem, was viele Leute glauben). Der Begriff „Story Point“ kommt im Scrum-Leitfaden kein einziges Mal vor. Der Leitfaden erwähnt zwar die Schätzung des Backlogs, allerdings wird nichts darüber gesagt, welche Art von Schätzung oder wie sie durchgeführt wird.

Sie wurden in Mike Cohns einflussreichem Buch „Agile Estimating and Planning“ von 2005 popularisiert. Mike Cohn ist wahrscheinlich der bekannteste Autor und Blogger im Bereich Scrum, daher sind seine Praktiken sehr weit verbreitet.

Über das Thema Story-Points wird viel diskutiert. Mache sind begeistert und manche hinterfragen den Sinn von Story-Points oder man streitet sich darüber, wie es richtig gemacht wird. Aber das ist bei viele Themen der Fall, die mit Agilität, agilen Methodiken und/oder Rahmenwerken zu tun haben.

Teilweise sind diese Diskussionen auch recht erhitzt. Ich denke dabei zum Beispiel an Certified Scrum vs. Professional Scrum. Und dies ist auch der Fall beim Thema Story-Points. Aber bevor ich über das Für und Wider von Story-Points schreibe, möchte ich den Leser dieses Beitrags, der mit Scrum nicht vertraut ist, kurz die Strukturen eines Scrum Teams nähe bringen. Ist auch ganz einfach, versprochen.

teaml

Das Scrum Team

Ein Scrum Team besteht aus den Rollen „Product Owner“, „Scrum Master“ und „Entwicklerteam“. Es gibt nur diese Rollen und keine Hierarchien. Die Entwickler (nicht zwingend Programmierer) arbeiten selbstorganisiert. Darüber hinaus kennt Scrum folgende Events: Sprint Planning, Daily Stand-up/Daily Scrum, Sprint Review und die Retrospektive.

story-points

Sprint Planning

Der Product Owner ist verantwortlich für das Aufnehmen der Anforderungen der Kunden/Stakeholder und das Begleiten und Unterstützen der Kunden/Stakeholder auf dem Weg zum erwünschten Ziel (Produkt). Diese Anforderungen (User Stories) werden auf einem sog. Product Backlog (ein physisches oder digitales Artefakt) aufgelistet und während des Sprint Plannings wird mit dem Entwicklerteam erörtert, welche Einträge (Items) durch das Entwicklerteam während eines Sprints (zwei bis vier Wochen) umgesetzt werden können.

Da diese User Stories recht komplex und/oder aufwendig sein können, ist es oft nicht leicht zu schätzen, ob eine Story innerhalb eines Sprints realisiert werden kann. Als Unterstützung werden dann gerne Story Points genommen. Dabei schätzt jedes Mitglied des Entwicklerteams (und nur die Entwickler) den Aufwand/Komplexität einer Story anhand einer Punktzahl ein. Nachdem jedes einzelne Teammitglied (Entwickler) seine Punktzahl gewählt hat, werden alle Ergebnisse öffentlich gezeigt. Bei Ergebnissen, die sich stark unterscheiden, wird diskutiert und meistens ein Kompromissergebnis erörtert. Nachdem die Einträge aus den Product Backlog gewählt wurden, landen diese in dem Sprint Backlog als „Aufgabenliste“ für das Entwicklerteam für den Sprint.

Selbstredend hat der Markt dafür Produkte entwickelt, die das Schreiben einer Zahl auf Papier ersetzen. Die Wirtschaft soll ja florieren. Es gibt ein Kartenspiel, dass sich Scrum Poker oder Estimation Poker nennt, aber es gibt auch die unterschiedlichsten online Tools, die ein Team beim Schätzen (Estimation) unterstützen.

Es liegt in der Natur der Sache, dass derartige Herangehensweisen gerne individuell interpretiert und durchgeführt werden. Nachfolgend gehe ich tiefer auf das Thema Story Points ein.

Was sind die Vorteile der Verwendung von Story-Points?

Mit Story Points kann ein Team:

  • Schnelles Schätzen von Problemen. Die Schätzung ist relativ zu bereits fertiggestellten Product Backlog Items. Dies ist schneller als eine Schätzung ohne Bezug.
  • Schätzen Sie, ohne eine bestimmte Zeitangabe zu machen. Wenn Sie in Stunden schätzen, gehen Sie eine genaue Zeitverpflichtung ein. Die Schätzung in Story-Points verhindert, dass Sie eine genaue Zusage machen. Niemand weiß genau, wie viele Stunden Sie für ein bestimmtes Thema veranschlagen.
  • Nehmen Sie die Ungewissheit in Kauf, die mit der Schätzung einhergeht. Story-Points geben einen unbekannten Zeitbereich an. Die Auswahl aus einer bestimmten Fibonacci-ähnlichen Folge von Story-Points erlaubt es, die Unsicherheit zu erfassen.
  • Genau genug, um Sprints im Voraus zu planen. So können wir die zeitlichen Erwartungen der Stakeholder für zukünftige Arbeiten besser steuern.

Teams denken, Story-Points seien nur Komplexität

Ich erwähne dies, weil ich zu viele Teams finde, die denken, dass Story-Points auf der Komplexität der User Story oder des Features basieren sollten und nicht auf dem Aufwand, sie zu entwickeln.

Solche Teams benennen „Story-Points“ oft in „Komplexitätspunkte“ um. Das klingt wohl besser. Anspruchsvoller vielleicht.

Aber es ist falsch.

Die Komplexität ist ein Faktor für die Anzahl der Punkte, die ein Product Backlog Item erhalten sollte. Aber sie ist nicht der einzige Faktor. Der Umfang der zu erledigenden Arbeit ist ein Faktor. Ebenso wie das Risiko und die Unsicherheit.

Zusammengenommen stellen sie den Aufwand dar, der mit der Entwicklung des Product Backlog Items verbunden ist.

Warum sind Story-Points besser als Stunden im Jahr 2021?

Bei den Mannstunden erwarten die Entwickler, dass sie genau die für den Sprint geschätzte Stundenzahl protokollieren. Aber das ist ein zweischneidiges Schwert. Wenn sie die geschätzte Anzahl von Stunden für einen Sprint überschreiten, dann deutet das darauf hin, dass sie eine schlechte Leistung erbringen. Wenn sie aber den Sprint unter der geschätzten Stundenzahl abschließen, dann bedeutet das, dass etwas mit der Schätzung nicht stimmt.

Story Points bieten vier wesentliche Vorteile gegenüber Mann-Stunden:

  1. Keine Korrelation mit den Fähigkeiten und der Erfahrung des Schätzers.

Wie wir bereits erwähnt haben, ist der Spezialist, der eine Aufgabe schätzt, nicht immer derjenige, der sie umsetzt. Senior- und Junior-Entwickler benötigen unterschiedlich viel Zeit, um die gleiche Aufgabe zu erledigen. Die einzige Möglichkeit, dies zu vermeiden, besteht darin, dass ein Entwickler, der ein Projekt schätzt, dieses Projekt auch implementiert.

Story-Points beseitigen dieses Problem, weil sie eine universelle Messung für das gesamte Team sind. Die Schätzung hängt nicht davon ab, wer die Story implementiert. Alle Teammitglieder mit unterschiedlichen Qualifikationsniveaus können sie gemeinsam diskutieren und zu einem einzigen Ergebnis kommen.

Das ganze Team kann sich ein klares Bild von der Größe und Komplexität der Story machen. Dies ist der Hauptvorteil von Story-Points.

  1. Velocity wird überwacht

Ein weiterer Schlüssel zur Leistungsfähigkeit der Story-Points Schätzung ist die Velocity. Velocity ist eine leistungsfähige Methode zur Kapazitätsplanung, die aufzeigt, wie viel Product Backlog-Aufwand ein Softwareentwicklungsteam in einem Sprint erfolgreich bewältigen kann. Das Ziel eines Teams ist es, seine Velocity zu erhöhen.

Die Teammitglieder besprechen während der Retrospektiven nach jedem Sprint, wie sie eine höhere Velocity erreichen können. Je höher die Velocity des Teams ist, desto höher ist die Fähigkeit des Teams, eine bestimmte Aufgabe schneller und effizienter zu erledigen.

Aber Velocity ist ein relativer Wert, der sich im Laufe des Projekts ändern kann. Und hier finden wir den nächsten Vorteil – Sie müssen Ihr Projekt nicht neu schätzen, wenn sich die Velocity ändert, während die Schätzung in Mannstunden eine Neuberechnung erfordern würde.

Wie man das Sprint Planning mithilfe Story-Points richtig durchführt

plan

Wie man User Story Points schätzt

Bei der Berechnung der Story-Points geht es um den Gesamtaufwand, der erforderlich ist, um das Feature oder die Funktionalität zum Leben zu erwecken, damit es dem Kunden einen Mehrwert bietet. Ihr Team muss Fragen diskutieren wie:

  • Wie komplex ist die Arbeit?
  • Wie viel Arbeit ist erforderlich?
  • Was sind die technischen Fähigkeiten des Teams?
  • Wie hoch sind die Risiken?
  • Bei welchen Teilen sind wir uns unsicher?
  • Was müssen wir vorbereiten, bevor wir beginnen oder fertigstellen können?
  • Was könnte schief gehen?

Tipp: Wenn Sie Schwierigkeiten haben, eine Story abzuschätzen, oder der Arbeitsumfang überwältigend ist, muss Ihre Story vielleicht in kleinere Teile zerlegt werden, oder sie sollten eine umfangreiche Story vielleicht auf mehrere Stories aufteilen.

Was ist jeder Story-Point „wert“?

An dieser Stelle können Story-Points ein wenig verwirrend sein, da Story-Punkte keinen festgelegten universellen Wert haben. Sie müssen irgendwie herausfinden, was sie für Sie und Ihr Team wert sind (ja, wirklich tiefes und bedeutungsvolles Zeug).

So funktioniert es:

Jeder Story wird eine bestimmte Anzahl von Story-Points zugewiesen.

Die Punkte bedeuten für verschiedene Teams oder Organisationen unterschiedliche Dinge

1 Story-Punkt für Ihr Team entspricht nicht unbedingt dem Aufwand, den 1 Story-Point für ein anderes Team bedeutet.

Der Aufwand für 1 Story Point sollte für Ihr Team in jedem Sprint stabil bleiben und auch von einer Story zur nächsten gleichbleiben.

2 Story Points sollten dem doppelten Aufwand im Vergleich zu 1 Story-Point entsprechen.

3 Story-Punkte sollten dem dreifachen Aufwand im Vergleich zu 1 Story-Points entsprechen… und so weiter

Die Zahl, die Sie vergeben, spielt keine Rolle – was zählt, ist das Verhältnis. Die Story-Points sollen Ihnen helfen, den relativen Aufwand zwischen jeder Story und jedem Sprint zu demonstrieren

Verwendung der Fibonacci-Folge für die Story-Point-Schätzung

story point fibonacci number

Einige Teams verwenden die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21, 34, 55, 89 usw.) für ihre Storypoint-Schätzungen, anstatt linear zu bleiben oder den Teams zu erlauben, eine beliebige Zahl (1, 2, 3, 4, 5, 6, 7 usw.) zu verwenden.

Das hat seine Vorteile. Wenn Sie z.B. eine Story betrachten und versuchen zu schätzen, ob es sich um eine 5, 8 oder 13 handelt, ist es viel schneller und einfacher, eine Antwort zu finden, als zu versuchen, auf die richtige Zahl zwischen, sagen wir, 4-15 zu kommen. Sie werden wahrscheinlich viel schneller einen Konsens erreichen.

Das bedeutet auch, dass Sie nicht in der Lage sein werden, den Durchschnitt der Story-Points des Teams zu ermitteln, um die Schätzung abzuschließen. Stattdessen müssen Sie die Arbeit diskutieren und sich für die beste Schätzung aus einer begrenzten Anzahl von Optionen entscheiden.

Aber es schränkt Ihre Möglichkeiten ein – wenn Sie eine Story haben, die mehr Aufwand als 34, aber weniger als 55 bedeutet, könnte Ihre Schätzung weniger genau sein.

Verwenden von Story-Points zum Schätzen der Geschwindigkeit Ihres Teams

velocity

Nach einiger Zeit der Zusammenarbeit werden die meisten Teams eine gute Vorstellung davon haben, wie viel Aufwand in jedem Story-Point steckt.

Natürlich ist das Timing nicht exakt – es gibt eine Glockenkurve, und Story-Points sind als Schätzung des Aufwands gedacht, nicht der Zeit.

Aber Story-Points (und das Wissen um deren ungefähre Zeiteinteilung) können nützlich sein, wenn es darum geht, herauszufinden, wie viel Ihr Team in jedem Sprint erledigen kann.

Sie sollten in der Lage sein, ungefähr so viele Story-Points abzuschätzen, wie Ihr Team in einem zweiwöchigen Sprint schaffen kann, oder in welchem Zeitrahmen Sie auch immer arbeiten wollen.

Wenn Ihr Team z. B. normalerweise 3 Story Points pro Tag schaffen kann, sind das in einem zweiwöchigen Sprint vielleicht 30 Story-Points. Dies ist Ihre Velocity.

Wie Sie sehen, gibt es ein paar verschiedene Methoden, um Arbeit zu schätzen. Der beste Rat ist, konservativ zu sein und das Team nicht zu überlasten.

Mit der Zeit sollten Ihre Schätzungen immer genauer werden.

Weitere Literatur über verwandte Themen, finden Sie hier und hier.

Schreibe einen Kommentar