Agile-Teams leben oder sterben durch ihre Sprint-Velocity. Wenn eure Zahlen von Sprint zu Sprint stark schwanken, ist das nicht nur nervig – es zeigt, dass euer Prozess kaputt ist.
Lass uns anschauen, warum die Velocity instabil wird – und wie man das fixt, bevor es euer ganzes Planning zerlegt.
1. Vage oder überhastete Schätzungen
Wenn dein Team 30 Sekunden pro Task braucht und einfach eine Zahl sagt, sind schlechte Schätzungen vorprogrammiert. Ohne Diskussion und Konsens sind Story Points oft reine Spekulation.
✅ Lösung: Nutzt Planning Poker, um Nachdenken und Gespräche zu fördern. Anonyme Abstimmungen und strukturierte Runden decken Missverständnisse vor dem Sprintstart auf.
2. Scope Creep während des Sprints
Ändern sich Stories mitten im Sprint? Werden Bugs oder Zusatzaufwand heimlich reingeschoben?
✅ Lösung: Klare Definition of Done-Regeln festlegen und Bugs separat schätzen. Wenn sie viel Zeit fressen, werden sie wie normale Tasks behandelt.
3. Ständig wechselndes Team
Urlaub? Neue Devs mitten im Sprint? Wenn sich die Kapazität ständig ändert, tut es die Velocity auch.
✅ Lösung: Verfolge die Verfügbarkeit des Teams und passe die erwartete Velocity entsprechend an – nicht einfach alte Zahlen weiterverwenden.
4. Uneinheitliche Story-Points
Wenn eine „5“ mal einen halben Tag dauert und mal drei Tage – ist eure Skala unbrauchbar.
✅ Lösung: Etabliert interne Referenz-Tasks pro Punktzahl (z. B. „Diese Story ist eine 3, so wie unser Login-Modal aus Sprint 12“).
5. Keine Rückschau auf vergangene Sprints
Ohne Rückblick keine Verbesserung.
✅ Lösung: In der Retro prüfen, wie genau eure Schätzungen waren. Wenn 8er-Tasks immer unterschätzt werden, müsst ihr eure Bewertung überdenken.
Fazit
Unstabile Velocity = unstabile Planung. Und die kommt oft durch schlechte Schätzgewohnheiten. Wechselt zu strukturierten Methoden wie Planning Poker und bekommt wieder Vorhersehbarkeit — ohne langsamer zu werden.