Bugs passieren. Sie zu ignorieren oder wie Aufgaben zweiter Klasse zu behandeln, ist das, was den Sprint wirklich ruiniert. Lass uns anschauen, wie man Bugs in Scrum richtig schätzt, ohne den Flow oder die Velocity des Teams zu killen.
Sollte man Bugs überhaupt schätzen?
Ja. Bugs kosten Zeit. Zeit ist Aufwand. Aufwand sollte geschätzt werden.
Aber nicht jeder Bug ist gleich:
- 🐛 Kleiner kosmetischer Fehler? Einfach fixen.
- 🐞 Komplexer Regression-Bug? Wie eine Story behandeln.
- 🚨 Kritischer Prod-Bug? Sofort beheben, später schätzen.
Fazit: Schätze Bugs, wenn sie Einfluss auf eure Velocity haben oder mehr als ~15 Minuten dauern.
Wie man Bugs in Story Points schätzt
Bugs sind oft weniger vorhersehbar als Features. So gehst du damit um:
- 📊 Gleiche Skala verwenden wie bei Stories (z. B. Fibonacci).
- 🧠 Aufwand für Analyse mit einbeziehen, nicht nur den Fix.
- ⚖️ Balance zwischen Genauigkeit und Geschwindigkeit — im Zweifel grob schätzen und später anpassen.
Beispiel:
Bug: "Login wirft 500er nach OAuth" Story Points: 3 (inkl. Debugging, Fix, Retests)
Wohin mit Bugs im Sprint?
Du hast Optionen:
- ⏩ In den Sprint — wenn der Bug vor dem Planning bekannt ist.
- ⛔ Außerhalb des Sprints — bei kritischen Hotfixes (separat tracken).
- 📥 In den Backlog — wenn nicht dringend, wie jede andere Aufgabe behandeln.
Halte dein Board sauber: keine Überraschungs-Bugs mitten im Sprint.
Häufige Fehler beim Bug-Schätzen
- ❌ Gar nicht schätzen — zerstört eure Velocity-Daten.
- ❌ Jeden Bug als kritisch behandeln — Fokus geht flöten.
- ❌ Alle Bugs in eine generische „Bugfix“-Aufgabe packen — verschleiert Komplexität.
Kein Faulenzen. Jeder Bug ist anders. Gib ihm die Aufmerksamkeit, die er verdient.
Wie ScrumPoker.it helfen kann
Ja, auch Bugs kannst du mit ScrumPoker.it schätzen. Ideal für:
- 🔒 Anonyme Abstimmung, wenn keiner „8“ sagen will
- ⏱️ Schnelle Schätzrunden beim Grooming
- 💬 Diskussionstrigger bei komplexen Bugs
Einfach den Bug in die Session werfen — und in Sekunden einen Konsens finden.
🎯 Jetzt einen Bug schätzen
FAQs
❓ Zählen Bugs zur Velocity?
Ja. Wenn sie geschätzt sind und Teil des Sprints, gehören sie dazu.
❓ Wie schätzen wir unerwartete Bugs?
Gar nicht. Separat tracken (z. B. mit Tag „Ungeplante Arbeit“) und im Sprint-Retro besprechen.
❓ Was, wenn QA nach Sprintstart Bugs findet?
Triage machen. Wenn kritisch — sofort fixen und loggen. Wenn nicht — in den Backlog für später.
Fazit
Bugs sind kein Nebengedanke — sie gehören zur Entwicklung. Schätze sie wie Stories, und dein Sprint-Plan bleibt stabil.
🛠️ Respektiere den Bug. Schätze ihn. Tracke ihn. Fixe ihn. Dein Team (und dein Velocity-Chart) werden es dir danken.