Strategien für den Umgang mit Bugs während des Sprints
Hier ein weiteres überraschend beliebtes Thema, das viele verwirrt. Was tun, wenn Sie während einer Iteration einen Bug finden? Sofort daran arbeiten oder aufschieben? Auf dem Task Board tracken oder lohnt die Zeit nicht? Die Antwort ist eigentlich nicht kompliziert. Schauen wir hin.
Im Wesentlichen gibt es nur drei Wege, mit einem neu entdeckten Bug umzugehen:
- jetzt fixen,
- später fixen,
- ignorieren.
Welche Strategie passt, hängt fast ausschließlich von zwei Dingen ab: der Kritikalität des Bugs und der erwarteten Fix-Zeit. Schauen wir uns jede Strategie genauer an.
Jetzt fixen
Was tun. Sofort im aktuellen Sprint fixen.
Wann anwenden. Die Strategie ist sinnvoll in einem von zwei Fällen: Der Bug ist schnell zu fixen — dann ist Sofort-Fix leichter und günstiger; oder er ist kritisch — dann bleibt kaum eine Wahl.
Wie tracken. Viele Fragen betreffen speziell Non-Production-Bugs, die während der aktiven Entwicklung einer User Story gefunden werden. Sie können auf viele Arten tracken – am einfachsten gar nicht. Das funktioniert am besten bei kleinen Bugs, die in wenigen Stunden fixbar sind, und spart unnötige Bürokratie.
Das ist aber nicht immer die beste Option. In den meisten Fällen wollen Sie den Bug trotzdem visualisieren, weil er die User Story blockiert – und Blocker gehören aufs Board. Es gibt ein paar Möglichkeiten.
Auf einem physischen Board legt man typischerweise einen roten Sticky über die Karte in Progress. Das kann ein größeres Blatt mit Zusatzinfos oder nur ein kleiner roter Aufkleber sein. Wenn der Bug gegen Ihre WIP-Limits zählen soll (falls Sie welche haben), können Sie zusätzlich eine eigene Karte neben dem roten Sticker legen. Sie belegt Platz und zählt zum Limit der Spalte – das motiviert das Team, den Bug zu fixen.
Bei digitalen Tools hängen die Optionen stark von der Software ab. Nehmen wir Jira als Beispiel. Am besten hat bei mir ein eigener Issue-Typ Sub-bug funktioniert (der Name ist egal) – eine weitere Variante von Sub-tasks. Sinnvoll ist auch, die Story zu flaggen für noch klarere Visualisierung – das Analogon zum roten Sticker auf dem physischen Board. Eine erstklassige Bug-Entität ist natürlich auch möglich, mit derselben Logik wie im physischen Beispiel.
Später fixen
Was tun. Ein neues Backlog-Item anlegen und ins Product Backlog legen. Danach wird der Bug wie jedes andere Backlog-Item für künftige Iterationen geplant.
Wann anwenden. Manchmal ist der Bug zwar kritisch, aber nicht kritisch genug für sofortigen Fix – besonders wenn er groß wirkt. Das gilt für Production-Bugs und für Bugs, die während der aktiven Story-Entwicklung gefunden wurden.
Wie tracken. Neue Karte anlegen und ins Backlog legen. Wenn Sie eigene Kartentypen für Bugs haben (meist ja), nutzen Sie sie. Auf physischen Boards sind rote Stickys für Bugs üblich; in Tools wie Jira gibt es standardmäßig den Typ Bug oder Defect.
Ignorieren
Was tun. Nun … nichts.
Wann anwenden. Manchmal lohnt es sich gar nicht, sich um den Bug zu kümmern. Das kann passieren, wenn der Fix relativ schwer wirkt und der Schaden bei Nicht-Fixen winzig ist. Sie akzeptieren das Risiko mit dem Gedanken: Wenn es wirklich wichtig ist, wird der Bug irgendwann erneut gemeldet.
Wie tracken. Sie tracken ihn nicht. Wenn Sie schon eine Weile daran gearbeitet und eine Karte haben, entfernen Sie die Karte einfach vom Board.
Production- und Non-Production-Bugs
Auf den ersten Blick wirken Production- und Non-Production-Bugs unterschiedlich. Aber der Unterschied ist nicht so groß. Ist der Bug klein oder extrem kritisch, fixen Sie ihn besser sofort – egal wann Sie ihn gefunden haben. Ist er zu groß für jetzt fixen, kommt er ins Backlog – wieder unabhängig vom Timing. In anderen Fällen investieren Sie einfach keine Zeit. Der einzige Unterschied liegt darin, wie Sie die Kritikalität bewerten. Bei Production-Bugs neigen Sie stärker zu später fixen, weil sie oft größer sind und mehr Arbeit brauchen. Bei Non-Production-Bugs ist in den meisten Fällen jetzt fixen sinnvoller, solange der Kontext noch frisch ist.