Story Points im Scrum

Story Points im Scrum – Story Points polarisieren. Für die einen sind sie ein mächtiges Werkzeug, um agile Vorhaben steuerbar zu machen. Für andere sind sie nutzlose Zahlen, die nur Berichte schöner aussehen lassen. In vielen Organisationen werden Story Points eingeführt – und nach wenigen Sprints frustriert wieder „stillgelegt“.

Dieser Beitrag zeigt, wie Story Points im Scrum wirklich funktionieren, was sie leisten (und was nicht) und wie Sie sie in Projekten mit Management‑Druck, festen Terminen und komplexen Abhängigkeiten sinnvoll einsetzen. Mit klaren Beispielen, konkreten Vorgehensschritten und typischen Stolperfallen aus der Praxis.

Story Points im Scrum
Story Points im Scrum

Was sind Story Points im Scrum?

Story Points sind eine relative Maßeinheit, mit der ein Scrum‑Team den Aufwand einer User Story im Vergleich zu anderen Stories einschätzt – basierend auf:

Wichtig:

Warum Story Points statt Stunden?

Typische Probleme bei Stundenschätzungen

Wer Projekte über Stunden plant, kennt diese Muster:

Gerade in komplexen Vorhaben (neues Produkt, neue Technologie, wechselnde Anforderungen) sind Stunden-Schätzungen trügerisch präzise.

Vorteile von Story Points

Story Points lösen diese Probleme nicht magisch, aber sie ändern den Fokus:

  1. Relativ statt absolut
    • Frage: „Ist diese Story ungefähr doppelt so aufwendig wie jene?“
    • Das fällt Teams deutlich leichter als exakte Stundenangaben.
  2. Diskussion über Inhalt statt über Zeit
    • Schätz-Workshops zwingen das Team, Unklarheiten, Risiken und technische Schulden offen zu legen.
    • Die Zahl (Story Points) ist nur Ergebnis dieser Diskussion.
  3. Bessere Prognosen über Velocity
    • Nach einigen Sprints kennt ein Team seine typische Velocity (z. B. 35–45 Story Points pro Sprint).
    • Damit werden Aussagen möglich wie: „Für 200 Story Points brauchen wir voraussichtlich 5–6 Sprints.“
  4. Schutz vor Mikromanagement
    • Solange Story Points nicht in Stunden „zurückgerechnet“ werden, entziehen sie sich dem direkten Vergleich von Personen oder Teams.

Wofür Story Points im Scrum konkret genutzt werden

In der Praxis erfüllen Story Points drei zentrale Aufgaben:

  1. Aufwandsschätzung im Product Backlog
    • Der Product Owner kann besser priorisieren, weil Nutzen und Aufwand sichtbar werden.
    • „Quick Wins“ (viel Nutzen, wenige Punkte) werden erkennbar.
  2. Sprint Planning
    • Das Team wählt für einen Sprint genau so viele Stories, wie es typischerweise schafft (basierend auf der historischen Velocity).
  3. Prognosen und Roadmaps
    • Management erhält belastbare, aber nicht überpräzise Aussagen:
      • „Mit dem aktuellen Team schaffen wir voraussichtlich XY Punkte bis zum Release.“
      • „Wenn wir mehr liefern wollen, brauchen wir mehr Sprints oder müssen Scope reduzieren.“

Wie Story Points in Scrum eingeführt werden – Schritt für Schritt

1. Startpunkt definieren: Referenz‑Story auswählen

Suchen Sie gemeinsam im Team eine reale User Story, die:

Beispiele:

Geben Sie dieser Story eine Story‑Point‑Zahl, z. B.:

Wichtig: Nicht zu lange diskutieren. Es reicht, wenn das Team zustimmt: „Das fühlt sich nach 3 (oder 5) an.“

2. Bewertungsmaßstab festlegen

Definieren Sie gemeinsam grob, wofür die Skala steht. Zum Beispiel:

Halten Sie dies stichpunktartig fest (z. B. als „Estimation‑Cheat‑Sheet“ im Wiki).

3. Schätzmethode wählen: Planning Poker in der Praxis

Planning Poker ist die verbreitetste Methode, um Story Points zu vergeben.

Vorgehen:

  1. Der Product Owner erklärt eine Story.
  2. Das Team stellt Fragen, klärt Akzeptanzkriterien und Randbedingungen.
  3. Jeder wählt verdeckt eine Karte (z. B. 2, 3, 5, 8…).
  4. Alle decken gleichzeitig auf.
  5. Bei starken Abweichungen (z. B. 3 vs. 13) erklären die „Extremwerte“ ihre Sicht.
  6. Erneute Schätzung, bis ein gemeinsamer Wert gefunden ist (oder eine sinnvolle Spanne).

Ziele:

4. Große Stories konsequent splitten

Story Points helfen, „Monster‑Stories“ zu erkennen. Wenn eine Story mit:

Story ist zu groß oder zu unklar. Sie sollte in kleinere Stories zerlegt werden.

Splitten Sie z. B. nach:

Zielgröße:

Beispiel: Story Points im Sprint Planning

Nehmen wir an, ein Scrum‑Team hat über die letzten 5 Sprints folgende Velocity erzielt:

Durchschnittliche Velocity: ca. 32–34 Punkte pro Sprint.

Im nächsten Sprint Planning geht das Team wie folgt vor:

  1. Der Product Owner stellt priorisierte Stories im Product Backlog vor.
  2. Das Team prüft, ob Stories bereits geschätzt sind (Story Points vorhanden).
  3. Für ungeschätzte Stories erfolgt eine schnelle Nachschätzung (Planning Poker „light“).
  4. Das Team nimmt Stories mit insgesamt etwa 30–34 Punkten in den Sprint – abhängig von:
    • anstehenden Abwesenheiten
    • zusätzlichen Aufgaben (z. B. Produktivsupport)
    • Risiken im Sprint

So entsteht ein realistisch gefüllter Sprint, ausgerichtet an der historischen Leistungsfähigkeit, nicht an Wunschzahlen.

Story Points und Velocity: richtig nutzen, falsch vermeiden

Was ist Velocity?

Velocity beschreibt die Summe der Story Points, die ein Team in einem Sprint tatsächlich abgeschlossen hat (Definition „Done“ erfüllt).

Beispiel:

Wofür Velocity sinnvoll ist

Wichtige Regeln im Umgang mit Velocity

Warum?

Praktische Leitplanken: Do’s & Don’ts bei Story Points

Do’s – bewährte Praktiken

Don’ts – typische Fehlanwendungen

Häufige Fragen zu Story Points im Scrum

Sind Story Points im Scrum verpflichtend?

Nein. Der Scrum Guide schreibt Schätzung vor, aber keine bestimmte Methode. Viele Teams nutzen Story Points, andere:

Entscheidend ist, dass das Team verlässlich planen und Prognosen abgeben kann. Story Points sind dafür ein erprobtes Werkzeug, aber nicht das einzige.

Wie viele Story Points sollte ein Team pro Sprint schaffen?

Es gibt keinen „richtigen“ Wert. Die Velocity ist immer:

Gute Praxis:

Wie gehe ich mit starken Schätzabweichungen um?

Wenn Stories regelmäßig deutlich mehr Aufwand erzeugen als ihre Story Points suggerieren, prüfen Sie:

Passen Sie daraufhin:

Story Points im Spannungsfeld Management & Controlling

In vielen Organisationen treffen Story Points auf:

Richtiger Umgang mit Erwartungen

  1. Transparenz schaffen
    • Erklären, dass Story Points ein internes Team‑Instrument sind.
    • Velocity als Bandbreite darstellen (z. B. „30–35 Punkte“), nicht als fixe Zahl.
  2. Brücke zu klassischen Größen schlagen
    • Grobe Überschätzungen können erfolgen, aber nicht als „harte“ Umrechnung:
      • z. B. „Historisch schafft dieses Team 30–35 Punkte bei 5 Vollzeitkräften → rund X Personentage je Sprint.“
    • Wichtig: Diese Brücke dient nur der Kommunikation nach außen, nicht als Zwang für interne Schätzungen.
  3. Scope statt Menschenzahl optimieren
    • Kommt Druck wie „Wir brauchen mehr Output – erhöht die Velocity“, ist die Antwort:
      • „Velocity ist Ergebnis, kein Hebel. Wir können Scope priorisieren, vereinfachen oder auf mehrere Releases verteilen.“

Konkretes Implementierungsszenario: Einführung von Story Points in einem bestehenden Projekt

Angenommen, Sie verantworten ein laufendes Projekt mit:

So können Sie Story Points schrittweise einführen:

  1. Workshop mit Product Ownern und Scrum Mastern
    • Ziel: gemeinsames Verständnis von Story Points, Nutzen und Grenzen.
    • Entscheidung für eine einheitliche Skala (z. B. Fibonacci).
  2. Pilot‑Team festlegen
    • Ein Team beginnt, Story Points im Refinement und Sprint Planning zu nutzen.
    • Parallel bleiben Stunden für externe Berichte (Übergangsphase).
  3. Kalibrierung über reale Stories
    • 10–20 bestehende Stories rückwirkend einschätzen („Was wäre das in Punkten gewesen?“).
    • Auf Basis der letzten Sprints grobe Velocity ableiten.
  4. Management‑Einbindung
    • Regeltermin, in dem Velocity und Prognosen vorgestellt werden.
    • Erwartungsmanagement: Bandbreiten, keine Fixzahlen.
  5. Rollout auf weitere Teams
    • Erfahrungen des Pilot‑Teams nutzen (Best Practices, Stolperfallen).
    • Gemeinsame Referenzbeispiele und Guidelines erstellen.
  6. Retrospektiven nutzen
    • In jeder Retrospektive kurz reflektieren:
      • „Haben uns Story Points geholfen, besser zu planen?“
      • „Wo hatten wir Fehlgriffe in der Schätzung – warum?“

Typische Missverständnisse über Story Points – und wie Sie sie auflösen

1. Missverständnis : „Story Points machen uns objektiver.“

2. Missverständnis : „Mit Story Points kann ich Teams vergleichen.“

3. Missverständnis : „Mehr Story Points = mehr Wert.“

Praxisempfehlungen für Entscheider und Projektverantwortliche

Wenn Sie als Führungskraft oder Projektmanager Story Points im Scrum‑Umfeld einsetzen (oder neu einführen) wollen, achten Sie besonders auf:

  1. Rolle des Managements
    • Geben Sie Rahmen und Ziele vor, aber mischen Sie sich nicht in einzelne Schätzungen ein.
    • Nutzen Sie Velocity und Story Points zur Portfolio‑Steuerung, nicht zur Kontrolle einzelner Mitarbeiter.
  2. Qualität der Product Owner
    • Gute Backlog‑Pflege und klare Akzeptanzkriterien sind entscheidend.
    • Ohne gute Anforderungen bleiben Story Points Glücksspiel.
  3. Team‑Stabilität
    • Ständige Teamwechsel oder paralleler Einsatz in mehreren Projekten verfälschen Velocity massiv.
    • Stabile Teams bringen deutlich bessere Prognosequalität.
  4. Verknüpfung mit Governance und Controlling
    • Akzeptieren Sie, dass agile Prognosen Bandbreiten liefern.
    • Passen Sie Berichtswesen und KPIs an (z. B. Fokus auf Durchlaufzeit, Lead Time, Defect Rate).

Fazit: Wann Story Points im Scrum wirklich sinnvoll sind

Story Points entfalten ihren Nutzen, wenn:

Sie sind weniger geeignet, wenn:

Richtig eingesetzt helfen Story Points im Scrum:

Wenn Sie Story Points in Ihrem Umfeld einführen oder „retten“ wollen und dabei Unterstützung bei Konzeption, Facilitation oder Management‑Enablement brauchen: Die Expert:innen der PURE Consultant begleiten seit vielen Jahren Organisationen genau bei diesen Fragestellungen – von der ersten Pilotierung bis zur skalierbaren agilen Governance.

Weitere Einträge