Bugs schätzen – ja oder nein?
In meinem vorherigen Beitrag habe ich die Frage beantwortet, was mit Bugs zu tun ist, die während einer Iteration gefunden werden. Danach haben einige gefragt, ob das Schätzen von Bugs sinnvoll ist und – wenn ja – wie. Offensichtlich gibt es nur zwei Optionen, und jede hat Vor- und Nachteile. Bevor wir Schlüsse ziehen, schauen wir uns beide an. Voraussetzung hier: Das Team arbeitet in Sprints und macht Sprint Planning.
Bugs nicht schätzen
- Hilft, sich auf Wertlieferung zu konzentrieren. Die Logik: Bei der Velocity zählt das Team nur neue Feature-Entwicklung – den Teil der Arbeit, der Endnutzerwert liefert. Bugs gelten als einer von vielen Faktoren, die die Velocity senken. Das soll das Team angeblich strenger machen, Bugs nicht entweichen zu lassen, weil niemand will, dass die Velocity auf null fällt. Das Gegenargument: Velocity ist eine schlechte Wertmetrik. Sie misst vor allem die Kapazität des Teams – und das ist nicht zwingend Wert.
- Langfristige Planung wird genauer. Bei der Langfristplanung schätzt man Bugs selten, weil sie zum Planungszeitpunkt noch unbekannt sind. Enthält die Velocity nur neue Features und der Forecast ebenfalls, kann man Forecast durch Velocity teilen und ein Zieldatum schätzen. Das Gegenargument: Neue Features kommen laufend ins Backlog, oft nach der Langfristplanung. Sie sind ebenso unbekannt wie Bugs – Bugs nicht zu schätzen macht es nicht leichter. Stattdessen liefert die Erfassung von Arbeitstypen (geplant, ungeplant, Bugs) genug Daten, um jeden Langfristforecast anzupassen.
- Bugs sind schwer oder unmöglich zu schätzen. Oft sind Bugs deutlich schwerer zu schätzen – besonders alte oder Produktionsbugs, weil der Kontext fehlt. Oft hat das Team den fehlerhaften Code gar nicht geschrieben. Man kann entgegnen, dass neue Stories genauso vage und schwer schätzbar sein können wie alte Bugs. Frische Bugs dagegen lassen sich relativ gut schätzen, weil der Kontext noch da ist und weniger Abhängigkeiten im Code bestehen.
Bugs schätzen
- Sprint-Planung wird deutlich einfacher. Am Ende ist Velocity eine Kapazitätsmetrik und soll dem Team helfen, die Kapazität für den nächsten Sprint einzuschätzen. Das wird einfacher, wenn alle Arten von Arbeit in die Rechnung einfließen.
Schätzen oder nicht schätzen?
Generell fühlen sich Teams mit dem Schätzen von Bugs deutlich wohler, und die Idee, nur „Neues“ zu messen, bringt nicht den erwarteten psychologischen Effekt. Früher hatte ich eine starke Meinung und bestand darauf, Bugs nicht zu schätzen. Mit der Zeit wurde mir klar: Wichtiger ist, Schätzungen so transparent, klar und konsistent wie möglich zu halten. Deshalb schätze ich Bugs in der Regel mit meinen Teams. Forecasting ist letztlich Aufgabe von Manager oder Agile Coach – wenn es für Sie komplizierter, für das Team aber einfacher wird, sollte das Ihr bevorzugter Weg sein.
Wie schätzen
Wenn Konsistenz bei Schätzungen zählt, ist die Antwort klar. Schätzen Sie Bugs genauso wie alles andere. Das heißt: Story Points mit Planning Poker – dann auch Planning Poker für Bugs. Bei Magic Estimation (finde ich hilfreicher) gehören Bugs ebenfalls aufs Schätzboard.