Kaum ein agiles Thema wird so erbittert diskutiert wie das Schätzen. Story Points, Planning Poker, Velocity – und am anderen Ende die Stimmen, die schlicht sagen: Lasst es ganz. Bevor wir über Methoden reden, lohnt deshalb die unbequeme Frage: Was willst du mit dem Schätzen eigentlich erreichen?
01 · EinordnungScrum Velocity berechnen und was die Rahmenwerke dazu sagen
Begrenzt stattdessen die parallele Arbeit (WIP), um den Fluss zu steuern.
Story Points, Planning Poker und Velocity stehen im Scrum Guide nirgends.
Macht vergleichbar, was sich kaum vergleichbar machen lässt.
Vorweg ein wichtiger Punkt: Schätzen auf Ticketebene ist keine Vorschrift. Die Methodik Kanban – kein Rahmenwerk, sondern ein Vorgehen, das sich über den bestehenden Prozess legt – verzichtet auf die Schätzung einzelner Aufgaben ganz und begrenzt stattdessen die parallele Arbeit (WIP), um den Fluss zu steuern. Scrum wiederum verlangt nur einen Forecast – die Einschätzung, ob das Ziel im Sprint machbar ist – und schreibt weder Story Points noch Planning Poker noch Velocity vor; im Scrum Guide steht von all dem nichts. Und Skalierungsframeworks wie SAFe gehen sogar dazu über, Story Points zwischen Scrum Teams anzugleichen (in SAFe „approximately normalized“ genannt) – also genau das vergleichbar zu machen, was sich, wie wir gleich sehen, kaum vergleichbar machen lässt. Wie du zu deiner Einschätzung kommst, ist also deine Entscheidung, nicht die des Rahmenwerks.
02 · KernDer eigentliche Wert: der Konflikt
Hier liegt der Punkt, den viele übersehen. Der Nutzen einer Schätzung steckt nicht in der Zahl, sondern in dem Gespräch, das sie auslöst. Sagt eine Person „3“ und die andere „11“, ist das kein Ärgernis, sondern ein Geschenk: Die eine hält die Aufgabe für trivial, die andere für hochkomplex. Genau dieser Konflikt macht sichtbar, dass beide etwas Unterschiedliches verstanden haben. Wer ihn auflöst – nachfragt, klärt, ein gemeinsames Bild herstellt –, kommt einen echten Schritt weiter in der Berechnung der Scrum Velocity für diesen Sprint. Schätzen ist damit vor allem ein Kommunikationswerkzeug im Projekt- wie Produktmanagement. Die zwei Fragen dahinter: Haben alle die Anforderung gleich verstanden – auch in ihrer Umsetzung? Und ist sie klein genug für einen Takt?
03 · MethodenDie Methoden im Überblick: Story Points, Planning Poker, Skalen
eine relative Größe, kein Zeitmaß. Sie bündeln Aufwand, Komplexität und Unsicherheit in eine Zahl, die nur im Vergleich zu anderen Aufgaben Sinn ergibt: Eine 8 steht für deutlich mehr als eine 3, aber sie meint keine acht Stunden im Kontext der Scrum Velocity.
Alle decken gleichzeitig auf. Genau das erzwingt den beschriebenen Konflikt, statt dass sich alle der ersten genannten Zahl anschließen.
Häufig eine Fibonacci-ähnliche Reihe (1, 2, 3, 5, 8, 13 …), weil größere Aufgaben naturgemäß unschärfer sind und die Berechnung der Story Points pro Sprint beeinflussen. Es geht aber auch anders – T-Shirt-Größen (S, M, L, XL) oder sogar Tiergrößen (Maus, Katze, Hund, Elefant). Die Skala ist zweitrangig; entscheidend ist das gemeinsame Gefühl für relative Größe.
04 · EbeneTicket oder ganzer Takt?
Auch hier gibt es kein Richtig. Manche Teams schätzen jedes einzelne Ticket, andere schauen nur auf den ganzen Sprint und fragen schlicht: Schaffen wir das oder nicht? Beides ist legitim – Scrum etwa verlangt, wie gesagt, nur den Forecast, nicht die Detailtiefe.
05 · VelocityVelocity des Teams – und warum sie trügt
Aus geschätzten Story Points entsteht die Velocity: wie viele Punkte ein Team pro Sprint im Schnitt abschließt. Das klingt nach einer harten Kennzahl, ist aber das Gegenteil. Der wichtigste Punkt zuerst: Velocity in Scrum beruht auf Zahlen, die geschätzt, geraten, im Zweifel aus der Glaskugel geholt sind. Eine Kennzahl ist immer nur so verlässlich wie ihre Grundlage – und diese Grundlage ist eine Schätzung.
Das hat handfeste Folgen. Wiederkehrende oder ähnliche Aufgaben schätzt ein Team mit der Zeit niedriger als am Anfang, weil sie zur Routine werden – die Velocity verschiebt sich, ohne dass sich die tatsächliche Leistung ändert. An einem optimistischen Tag verschätzt sich eine Runde schon mal komplett. Und streng genommen müsste man, um ehrlich zu messen, nach Abschluss noch einmal draufschauen: War das wirklich eine 5 – oder im Rückblick eher eine 8? Dann müsste die 8 in die Rechnung. Wer das konsequent zu Ende denkt, landet in einem Zahlenwerk, das in keinem Verhältnis mehr zum Nutzen steht.
Dazu kommen die offensichtlichen Faktoren: Urlaube, Krankheitstage, Teilzeit, Feiertage, Meetings, Onboarding neuer Leute, wechselnde Teamgrößen. Für eine wirklich belastbare Velocity müsste all das ebenfalls hinein. Spätestens hier wird klar: Der organisatorische Aufwand ist absurd hoch für das, was am Ende beim Sprint Planning herauskommt.
Velocity ist keine vergleichbare Metrik.
Und zwei Dinge bleiben unabhängig davon wahr. Velocity ist keine vergleichbare Metrik: Sie gilt nur fürs eigene Team und taugt nicht als Kennzahl fürs Management. Team A mit 40 Punkten ist nicht „besser“ als Team B mit 20, denn die Skalen sind frei gewählt und schlicht nicht vergleichbar. Und wer Velocity zum Bewertungsinstrument macht, erntet prompt aufgeblähte Schätzungen.
06 · AlternativeUnd wenn du gar nicht schätzt?
Damit sind wir bei der unbequemen Frage. Wenn der eigentliche Wert das gemeinsame Verständnis ist – brauchst du dafür zwingend Zahlen? Nein. Es gibt Ansätze, die ganz ohne Aufwandsschätzung auskommen (oft „No Estimates“ genannt): Aufgaben werden konsequent klein geschnitten, das gemeinsame Bild entsteht im Gespräch, und gesteuert wird über begrenzte parallele Arbeit (WIP-Limits) statt über Punkte. Fluss-Metriken wie Durchsatz und Durchlaufzeit machen den Fortschritt dabei sichtbar und ermöglichen Vorhersagen. Genau diesen Weg geht die Methodik Kanban. Der Forecast „Schaffen wir das?“ funktioniert auch so.
Unsere Haltung dazu ist deutlich: Du musst nicht auf Ticketebene schätzen, und du brauchst keine Story Points, um wirksam zu arbeiten. Was du brauchst, ist ein gemeinsames Verständnis und klein geschnittene Arbeit. Schätzen ist ein Mittel dorthin, kein Selbstzweck.
Für Scrum Master, Agile Coaches und den Product Owner heißt das konkret: Behandelt das Schätzen als Werkzeug, nicht als Pflichtprogramm. Wenn eure Schätzrunden nur noch Zahlen ausspucken, ohne dass ein echtes Gespräch entsteht, ist das ein Warnsignal. Stellt dann offen die Frage, was ihr eigentlich herausfinden wollt – und traut euch, das Schätzen zu vereinfachen oder zeitweise ganz wegzulassen, um zu sehen, ob euch wirklich etwas fehlt.
Eine Frage zum Schluss: Wofür nutzt ihr eure Schätzungen wirklich – um euch gemeinsam zu verstehen, oder um eine Sicherheit zu erzeugen, die es ohnehin nicht gibt?
Zahlen sind schnell gewürfelt. Ein gemeinsames Bild braucht Übung.
In der Guided Agile Community bringst du deine echten Schätzrunden mit und übst über drei Monate, wann eine Schätzung wirklich hilft und wann sie nur Sicherheit vortäuscht. Begleitet, mit Feedback und Menschen, die denselben Weg gehen.
Gründer der Guided Agile Community (GAC), PSM III-zertifiziert und Dozent an der Universität Hildesheim. Stefan begleitet Praktiker:innen dabei, agiles Wissen iterativ und praxisnah im Berufsalltag zu verankern.
Mehr über Stefan auf LinkedIn