Was sind Story Points im agilen Projektmanagement?
Story Points sind eine relative Maßeinheit, mit der agile Teams die Komplexität, das Risiko und damit den Aufwand einer Aufgabe (User Story) bewerten. Sie ersetzen Zeitschätzungen in Stunden oder Tagen und ermöglichen eine realistische, vergleichbare und personenunabhängige Aufwandsschätzung innerhalb von Scrum- oder Kanban-Teams. Story Points fördern den Teamdialog, verhindern Fehlkalkulationen und bilden die Basis für die Team Velocity, also die pro Iteration umgesetzte Arbeitsmenge.
Diese Definition ist leicht zu verstehen – die Umsetzung dagegen selten trivial. In unseren Projekten erleben wir immer wieder, dass der Umgang mit Story Points viel über das Verständnis von Agilität verrät. Viele Projektleiter kennen das: Die Aufwandsschätzung steht, doch die Realität sieht ganz anders aus. In klassischen Projekten wird akribisch in Stunden und Tagen geplant – oft mit dem Anspruch, alles exakt vorherzusagen. In der Praxis führt das selten zu Sicherheit, sondern eher zu Enttäuschung.
Agile Methoden stellen diesen Ansatz auf den Kopf. Statt alles im Voraus zu definieren, wird nur das geschätzt, was aktuell am wichtigsten ist: die Features mit dem höchsten Kundennutzen. Diese werden in User Stories heruntergebrochen und schrittweise umgesetzt. So entstehen Planbarkeit, Flexibilität – und echte Lernzyklen.
Die Frage lautet also nicht mehr: Wie lange dauert das gesamte Projekt?
Sondern: Wie viel Mehrwert können wir in der nächsten Iteration liefern?
Vom Projektplan zum Feature-Backlog: Prioritäten statt Perfektion
Im agilen Umfeld dient das Feature-Backlog als dynamische Roadmap. Jedes Feature ist eine Funktion mit erkennbarem Mehrwert für den Kunden. Das Backlog ist priorisiert: Oben stehen die Themen, die den größten Nutzen oder das größte Risiko tragen. Eine realistische Schätzung der oberen Features ist doppelt wertvoll:
- Sie macht Release-Planung und Roadmapping möglich.
- Sie hilft, Aufwand und Nutzen gegeneinander abzuwägen.
Praxis-Tipp:
In Projekten der S&N Group nutzen Teams häufig eine einfache Matrix: Kundennutzen vs. Aufwand (in Story Points). So lassen sich Features transparent priorisieren – und Quick Wins schneller umsetzen.
Von Features zu Stories: Kleine Einheiten, klare Ergebnisse
Bevor ein Feature umgesetzt wird, wird es in kleinere Stories zerlegt – Arbeitspakete, die innerhalb einer Iteration (z. B. einem Scrum-Sprint) abgeschlossen werden können. Dieses Vorgehen schafft Transparenz und Messbarkeit: Jede Story ist ein kleines, fertiges Ergebnis. Nach jedem Sprint kann das Team zeigen, was entstanden ist – und Kundenfeedback direkt einfließen lassen. Genau an dieser Stelle kommt das Schätzen mit Story Points ins Spiel. Dabei wird im Rahmen eines Planning Pokers jede Story geschätzt.
Warum Zeit kein gutes Maß ist
Zeitschätzungen wirken präzise, sind aber trügerisch. Ob eine Aufgabe zwei oder fünf Tage dauert, hängt von vielen unvorhersehbaren Faktoren ab:
- Wer setzt sie am Ende um?
- Welche Hindernisse tauchen auf?
- Wie reibungslos läuft die Zusammenarbeit?
Diese Faktoren beeinflussen die Schätzung mit Story Points nicht. In agilen Teams geht es nicht um Stunden, sondern um Komplexität, Unsicherheit und Aufwand. Das ist der Kern von Story Points. Welche Auswirkungen fehlende oder falsch verstandene Schätzungen in der Praxis haben können, zeigt folgendes Beispiel:
Erfahrungen aus einem Kundenprojekt
In einem Projekt aus dem Bankenumfeld arbeitete das Team mit User Stories und festen Sprintlängen, verzichtete jedoch bewusst auf jede Form der Aufwandsschätzung. Die Motivation dahinter war nachvollziehbar: Im Team bestand die Sorge, dass Schätzungen später zur Leistungsbewertung herangezogen würden. In der Praxis führte dieser Ansatz jedoch zu einem anderen Problem. Da unklar blieb, wie viel Arbeit realistisch in einen Sprint passt, konnten rund 90 % der geplanten Stories nicht abgeschlossen werden und wanderten regelmäßig in den nächsten Sprint.
Als das Team sich darauf einigte, Story Points testweise einzuführen, verlagerte sich die Diskussion im Planning Poker. Statt über Zeit zu sprechen, stand zunehmend die Frage im Mittelpunkt, ob eine Story innerhalb der Sprintlänge überhaupt sinnvoll umsetzbar ist. Viele Stories wurden daraufhin kleiner geschnitten oder neu strukturiert. Das Ergebnis: Bereits nach kurzer Zeit stieg die Abschlussquote auf über 90 %. An die Stelle von Frust über unerledigte Arbeit traten sichtbare Ergebnisse und ein spürbares Erfolgserlebnis im Team.
Dieses Beispiel zeigt, dass Story Points nicht zur Kontrolle dienen, sondern helfen, Arbeit realistisch zu strukturieren und planbar zu machen.
Story Points: Aufwand sichtbar machen
Story Points messen nicht benötigte Zeit, sondern den relativen Aufwand einer Story.
Teams schätzen gemeinsam, wie komplex oder riskant eine Aufgabe im Vergleich zu anderen ist. Ein gängiges Hilfsmittel ist die Fibonacci-Skala (1, 2, 3, 5, 8, 13, 21). Der wachsende Abstand zwischen den Zahlen drückt die zunehmende Unsicherheit bei großen Aufgaben aus.
Beispiel aus der Praxis
- 2 Punkte: Kleine, klar definierte Aufgabe (z. B. Button hinzufügen).
- 5 Punkte: Mittelgroße Story mit Abhängigkeiten (z. B. Formular mit Validierung).
- 13 Punkte: Komplexes Thema mit unklarer Schnittstelle oder neuem Framework.
Erfahrung aus der Praxis: Was oft schiefläuft
Viele Teams führen Story Points ein – und erleben Frust. Warum? Weil sie versuchen, sie in Stunden umzurechnen. Das zerstört den eigentlichen Zweck: relative Vergleichbarkeit und Unabhängigkeit von Personen.
Typische Stolperfallen
- Story Points als Leistungskennzahl missbraucht: Velocity wird zur KPI – das erzeugt Druck statt Vertrauen.
- Schätzungen ohne Referenzen: Ohne Beispiele aus der Vergangenheit bleibt jedes Team unsicher.
- Zu grobe Stories: Wenn eine Story zu groß ist, hilft keine Punktzahl – sie muss aufgeteilt werden.
Einblick in die Praxis
Bei der S&N Group beginnen Teams meist mit einer „Baseline Story“ – einer kleinen, bekannten Aufgabe mit festgelegten 2 Punkten. Alles andere wird im Vergleich dazu geschätzt. Nach wenigen Sprints entsteht so eine gemeinsame Sprache für Aufwand. In einem Kundenprojekt haben wir eine Referenz-Story-Tabelle erstellt, die beispielhafte Stories aus früheren Sprints charakterisiert und eine Komplexitätsangabe enthält. Die Komplexität wurde von Entwicklern im Vorfeld eines Sprints geschätzt und nach dem Sprint validiert, ob die Schätzung zutreffend war. In Folge-Sprints nutzen wir diese Referenz-Stories, um neue Stories mit ähnlichen Eigenschaften zu schätzen. Die folgende Tabelle zeigt beispielhaft Referenz-Stories aus einem S&N Kundenprojekt.
Team Velocity: Lernen aus Erfahrung
Nach einigen Iterationen zeigt sich, wie viele Story Points ein Team durchschnittlich umsetzt – die sogenannte Velocity. Sie ist keine Bewertung, sondern ein Erfahrungswert:
Wie viel kann dieses Team in diesem Kontext pro Iteration schaffen?
Die Velocity stabilisiert sich nach einigen Sprints und wird zur Grundlage für realistische Planung und Forecasting.
Aber: Sie darf nicht als Zielgröße missverstanden werden. Ein Team, das seine Velocity künstlich steigert, verliert den Fokus auf Qualität und Kundennutzen.
Wie schätzt man mit Story Points? Unsere Best Practices.
- Diskussion statt Abstimmung: Schätzen ist ein Lernprozess – unterschiedliche Einschätzungen sind wertvoll.
- Keine Umrechnung in Stunden: Das ist gegen den agilen Gedanken.
- Regelmäßig kalibrieren: Vergleicht neue Stories mit alten Referenzen.
- Große Stories aufteilen: Alles über 13 Punkten sollte zerlegt werden.
- Velocity als Lerninstrument verstehen: Nicht: „Wie schnell sind wir?“, sondern: „Was hindert uns?“
Vorteile in der täglichen Praxis
- Realistischere Planung: Teams planen mit Erfahrungswerten, nicht Wunschdenken.
- Bessere Priorisierung: Aufwand und Nutzen werden vergleichbar.
- Mehr Transparenz: Kunden und Stakeholder sehen Fortschritt in verständlicher Form.
- Teamverständnis wächst: Gemeinsames Schätzen fördert Kommunikation und Vertrauen.
Fazit: Story Points sind kein Ziel – sie sind ein Werkzeug zum Lernen
Story Points sind mehr als eine Schätzmethode. Sie sind ein Kommunikationsinstrument.
„Story Points fördern Diskussion statt Illusion. Beim gemeinsamen Schätzen entsteht Verständnis im Team – oft wertvoller als die Zahl selbst.“
Jürgen Tacken
Story Points schaffen ein gemeinsames Verständnis von Aufwand, fördern Dialog und ermöglichen kontinuierliche Verbesserung. Teams, die Story Points richtig einsetzen, gewinnen Planungssicherheit, ohne ihre Agilität zu verlieren. Wie wir agile Schätzmethoden auch in klassischen Projekten einsetzen, erzählen wir in einem nächsten Blog-Artikel. Stay tuned!
Sprechen Sie mit unseren Experten
Sie möchten Story Points in Ihrem Projektumfeld einführen oder Ihre agile Planung professionalisieren? Die S&N Group unterstützt Sie mit langjähriger Erfahrung aus agilen Softwareprojekten, Coachings und Transformationen.
🌐 Mehr erfahren: Agile Methoden
Über die Autoren
Die S&N Group begleitet Unternehmen bei der Einführung agiler Methoden, bei digitalen Transformationen sowie in anspruchsvollen Softwareprojekten. Unsere Expertinnen und Experten verbinden technologische Exzellenz mit agiler Umsetzungserfahrung aus über 35 Jahren Projektpraxis – mit dem Ziel, nachhaltige Lösungen zu schaffen, die im Arbeitsalltag wirklich funktionieren.
Dr. Jürgen Tacken hat zahlreiche Kunden der S&N Group als Scrum Master und agiler Coach begleitet. Seine Leidenschaft ist es, Teams so zu befähigen, dass agile Methoden echten Mehrwert liefern – und nicht nur auf dem Papier existieren. Der Fokus liegt dabei auf wirksamer Zusammenarbeit, klarer Kommunikation und einer Arbeitsweise, die Motivation, Vertrauen und erfolgreiche Projektergebnisse fördert.
Dr. Baris Güldali ist Methodenexperte für klassische und agile Softwareentwicklung. Seine Schwerpunkte liegen in der agilen Transformation und der kontinuierlichen Qualitätssicherung. Im Mittelpunkt seiner Arbeit stehen die Vermittlung geeigneter Methoden, deren praxisnaher Einsatz sowie die nachhaltige Befähigung von Projektteams. Seine fundierten Kenntnisse basieren auf umfangreicher Praxiserfahrung im Qualitätsmanagement sowie auf vielfältigen Forschungsaktivitäten. Darüber hinaus ist er als Mitglied im Leitungsgremium der Fachgruppe Test, Analyse und Verifikation von Software (TAV) der Gesellschaft für Informatik e. V. breit vernetzt.
