Agiles Schätzen – Wie funktionieren Planning Poker & Co.?

Pragmatisches Projektmanagement

Herzlich Willkommen zu einer neuen Ausgabe vom Pragmatischen Projektmanagement, deiner Quelle für Informationen und Inspiration zu alltäglichen Herausforderungen im Management von Softwareentwicklungsprojekten. Dich erwarten Einblicke, Erfahrungen und unsere individuellen Ansichten zu Methoden, Werkzeugen, Vorgehensweisen und Fragen aus dem Leben eines Projektmanagers.

Gern diskutieren wir mit Euch auf LinkedIn zu Euren Erfahrungen und Ansichten.

Warum habt ihr dafür drei Tage gebraucht?! Ich hätte das in einem halben Tag runterprogrammiert. Was bringen uns diese Story Points eigentlich? Ich will wissen, was es kostet.

Kommen dir solche Aussagen bekannt vor? Willkommen in der Grauzone zwischen Management-Erwartung und Entwickler-Realität. Agile Schätzmethoden wie Planning Poker oder T-Shirt Sizes sorgen immer wieder für Stirnrunzeln – nicht selten, weil sie auf den ersten Blick ungenau wirken. Doch richtig eingesetzt sind sie das beste Mittel gegen trügerische Präzision und unrealistische Pläne.

Warum schätzen wir überhaupt?

In klassischen Projekten gibt es oft ein Pflichtenheft, Deadlines und exakte Aufwandsschätzungen in Stunden. Das funktioniert so lange, wie die Anforderungen klar, die Technik bekannt und die Welt vorhersehbar ist. Also so gut wie nie. Agiles Arbeiten akzeptiert genau das: Komplexität, Unsicherheit, Wandel. Und braucht daher Werkzeuge, die damit umgehen können.

„Warum überhaupt schätzen? Wir wissen doch eh, dass es am Ende nie genau passt!“ – diesen Satz hört man oft. Und ja, exaktes Vorhersagen ist nicht das Ziel. Aber gute Schätzungen helfen trotzdem – auf drei Ebenen:

1. Verständnis klären Große Abweichungen in den Schätzungen sind ein Warnsignal: Sie zeigen, dass das Team ein unterschiedliches Verständnis der Aufgabe hat. Genau darin liegt der Mehrwert – denn wer hier diskutiert, verhindert später teure Fehlentwicklungen. Und wer ohne Diskussion schätzt, hat entweder triviale Aufgaben oder schlechte Schätzungen.

2. Vergleichbarkeit schaffen Schätzwerte helfen, ähnliche Stories miteinander zu vergleichen. Ob durch Erfahrung oder durch Tools wie KI-gestützte Analyse: Wenn eine Story „wie die von letzter Woche“ klingt, kann man Aufwand und Risiko besser einordnen.

3. Planbarkeit ermöglichen Story Points und andere Schätzmaße sind die Basis für eure Velocity – also die durchschnittliche Menge an Arbeit, die ein Team in einem Sprint schafft. Damit wird Planung auf Backlog-Ebene überhaupt erst sinnvoll möglich.

Was wir NICHT tun: Aufwand in Stunden schätzen

„Könnt ihr bitte mal kurz in Stunden schätzen?“ – Dieser Satz wirkt unschuldig, untergräbt aber schnell den Sinn agiler Planung.

Warum? Weil wir nicht hellsehen können. Stunden-Schätzungen täuschen eine Genauigkeit vor, die schlicht nicht realistisch ist – besonders bei komplexen oder unklaren Anforderungen. Außerdem: Wer in Stunden schätzt, lädt sich unnötig Diskussionen über persönliche Geschwindigkeit auf. Das erzeugt Druck, Vergleicherei und lähmt die Teamdynamik.

Story Points (oder ähnliche Maße wie T-Shirt-Sizes) abstrahieren bewusst: Sie schätzen relativ – also im Verhältnis zu anderen Aufgaben. Das hilft, Schwankungen auszugleichen, ohne in Diskussionen über einzelne Arbeitsstile zu verfallen.

Aber Moment – ist Schätzen in Stunden wirklich so schlimm?

Ganz ehrlich? Nicht immer. Auch wenn agile Lehrbücher gerne den Stab über Stunden-Schätzungen brechen, gibt es gute Gründe, warum Teams oder Stakeholder sich doch daran orientieren wollen:

• Stakeholder denken in Kalendern, nicht in Story Points. Wenn ein Kunde fragt, ob Feature X „nächste Woche fertig wird“, hilft es niemandem zu antworten: „Das ist eine 13.“ In solchen Fällen kann eine grobe Umrechnung („unser Team schafft im Schnitt 20 Punkte pro Sprint, also ca. 5–6 Punkte pro Woche“) tatsächlich Orientierung geben – wenn sie bewusst und verantwortungsvoll eingesetzt wird.

• Manche Aufgaben sind konkret und wenig risikobehaftet. Wenn klar ist, dass ein Task zwei Stunden dauert, muss man ihn nicht pseudowissenschaftlich in Story Points pressen. Hier darf man pragmatisch sein – gerade bei Routinearbeit.

• Kapazitätsplanung auf Wochen- oder Monatsebene funktioniert häufig besser mit einer Mischung aus relativen Schätzungen (für Komplexität) und absoluten (für grobe Zeitrahmen). Das gilt besonders bei externen Abhängigkeiten oder Schnittstellen.

Aber Vorsicht: Das Umrechnen von Story Points in Stunden kann schnell toxisch werden – vor allem, wenn es zur Leistungsbewertung einzelner Entwickler genutzt wird. Oder wenn daraus fixe Deadlines abgeleitet werden, ohne das übliche Maß an Ungewissheit in agilen Projekten zu berücksichtigen.

Wir merken uns: Stunden können ein hilfreiches Werkzeug sein, sie sollten aber nicht zum Maß aller Dinge werden. Der eigentliche Zweck von Schätzungen ist nicht Kontrolle, sondern Kommunikation und Orientierung. Und wenn ihr in Stunden schätzt, dann nutzt wenigsten 3-Punkt Schätzungen, um Unsicherheit und Risiko sichtbar zu machen.

Was tun, wenn es doch einen festen Termin gibt?

Auch wenn agile Teams nicht in Stunden schätzen – Deadlines existieren trotzdem. Manchmal muss ein Feature bis zu einem bestimmten Zeitpunkt fertig sein. Und das ist völlig legitim. Die Frage ist nur: Wie gehen wir damit um?

Die Antwort liegt im sogenannten magischen Dreieck des Projektmanagements: Wenn Zeit fix ist, bleiben nur noch Qualität (also z.B. funktionale und nichtfunktionale Anforderungen) und Kosten (z. B. Teamgröße oder Teamzusammensetzung), an denen du schrauben kannst. In der Praxis heißt das: Features reduzieren, Komplexität senken oder temporär zusätzliche Kapazität aufbauen.

👉 Mehr dazu findest du im Artikel zum magischen Dreieck.

Die gängigsten Methoden im Überblick

Die wohl bekannteste Methode zur agilen Schätzung ist das Planning Poker – ein Format, das in nahezu jedem Scrum-Training als Standard vermittelt wird. Kein Wunder: Die meisten Tools wie Jira, Azure DevOps oder Trello bieten dafür entweder integrierte Funktionen oder gut dokumentierte Extensions. So kann ein Team kollaborativ schätzen, ohne auf externe Hilfsmittel ausweichen zu müssen.

Beim Planning Poker wird nicht in Stunden oder Tagen geschätzt, sondern in abstrakten Größen. Der Fokus liegt nicht auf exakten Zahlen, sondern auf der relativen Komplexität und dem Aufwand im Vergleich zu anderen Stories. Das schützt vor Scheingenauigkeit und zwingt das Team zur inhaltlichen Auseinandersetzung mit der Aufgabe.

Typische Beispiele für abstrakte Größen:

• „Die Story ist etwa doppelt so komplex wie die Login-Funktion.“
• „Der Aufwand liegt irgendwo zwischen ‘E-Mail-Versand’ und ‘Datenmigration’.“
• „Ich sehe da eine 5 – wegen unklarer Schnittstellen.“

Um das zu erleichtern, hat sich eine Reihe von Skalen etabliert:

Planbarkeit mit abstrakten Größen?

Auch wer abstrakt schätzt, will konkret planen können – und genau hier kommt der Begriff Velocity ins Spiel. Die Velocity beschreibt die Menge an Story Points, die ein Team typischerweise in einem Sprint umsetzt. Sie ist also eine Art „Taktzahl“, die hilft, zukünftige Sprints besser planbar zu machen.

In eingespielten Teams pendelt sich die Velocity oft auf einen relativ stabilen Wert ein. Genau das macht sie so wertvoll: Man kann Backlogs durchrechnen, Liefertermine realistischer abschätzen und Engpässe frühzeitig erkennen.

Aber: Schwankungen in der Velocity sind nicht einfach nur Schwankungen – sie können wichtige Frühwarnsignale sein:

• Sind die Stories schlecht geschnitten oder formuliert?
• Fehlt Know-how im Team?
• Gibt es personelle Veränderungen oder Blocker?

Eine stark schwankende Velocity ist also kein Versagen des Teams, sondern ein Hinweis darauf, dass sich das System verändert hat – und dass es sich lohnt, genauer hinzuschauen. Zudem noch zwei Warnhinweise: ⚠️Velocity ist kein Ziel sondern ein sich ergebender Wert. Wer Zielwerte für die Velocity anstrebt, hat das Spiel nicht verstanden. ⚠️Und wer andererseits Teams auf Basis von Velocity vergleicht, der vergleicht Birnen mit Äpfeln.

Fazit: Schätzen ist Kommunikation

Agiles Schätzen ist keine exakte Wissenschaft, sondern ein Dialoginstrument. Es bringt Teams dazu, über Anforderungen, Risiken und Komplexität zu sprechen – und das ist der wahre Wert. Wer es richtig macht, bekommt keine perfekte Vorhersage, aber eine deutlich bessere Entscheidungsgrundlage.

Oder anders gesagt: Lieber ehrlich geschätzt als präzise daneben.

Im nächsten Teil unserer Serie geht es um die unterschätzten Stars im Schatten der Features: nichtfunktionale Anforderungen. Warum sie oft ignoriert werden, bis es zu spät ist – und wie du das besser machst. Bis dahin freue ich mich auf Eure Reaktionen auf LinkedIn.