Folge 5: Der geschätzte Bug

In Folge 5 geht es um Käfer. Wir wollen die kleinen Kerlchen aber nicht wertschätzen, sondern sprechen darüber, wie man in agilen Softwareprojekten mit Bugs umgehen kann. Anhand unserer eigenen Erfahrung beantworten wir die Fragen, ob es sinnvoll ist, Bugs zu schätzen, wie man Bugfixing transparent gestalten kann und wie man mit neu auftauchenden Bugs umgeht. Zu guter letzt sprechen wir über Bugtracker und Handhabung langer Buglisten.

Links

Pick der Woche

11 Gedanken zu „Folge 5: Der geschätzte Bug“

  1. Mir gefällt die Perspektive, dass Bugs die durchschnittliche Velocity reduzieren und damit die Planung realistischer machen. Das also Bugs nicht geschätzt werden.
    Ich habe aber aus einem Projekt auch schon mitgenommen, dass das Dev Team sich eher wertgeschätzt fühlt, wenn „Bugs“ als neue User Story auf das Board kommen. Dahinter stand die Annahme, dass bei der Abnahme einer User Storie die Akzeptanzkriterien offensichtlich erfüllt waren. Wenn also etwas nicht so funktioniert wie es soll, wurde es wohl nicht beim Schreiben der User Story berücksichtigt.

    Habt ihr Vergleichswerte zwischen:
    – Bugs sofort lösen -> Reduzierung der Velocity
    – Bugs als neue User Story bzw. Task

    Bzgl. Stimmung im Team; Anzahl Bugs / pro Sprint

    1. Das mit der Wertschätzung liegt daran, dass ganz klar definiert sein muss, was ein Bug ist. Wenn eine User Story nicht so ist, wie es sich der Product Owner vorgestellt hat, etwa weil er ein Akzeptanzkriterium vergessen hat, dann gehört das auf jeden Fall als neue Story ins Backlog und ist niemals ein Bug. Das gilt auch dafür, wenn der Product Owner eine Story abnimmt, dann aber feststellt, dass doch noch was fehlt. Das unterminiert sonst tatsächlich die Wertschätzung, die das Team fühlt und verwässert außerdem den Begriff Bug und den Begriff User Story. Ich habe nämlich keine Ahnung mehr, was eine User Story wirklich kostet und wie lange sie wirklich braucht, wenn ich noch im Nachhinein über Bugs Anpassungen vornehme.

      Zu den Vergleichswerten:
      Ich hatte mal ein Team, das Bugs „für spätere Sprints“ gesammelt hat. Die waren zwar nicht explizit im Backlog, es kam aber quasi aufs gleiche raus. Sowas frustriert ungemein und führt letztendlich zu Bug-Tagen/-Wochen/-Monaten. Im konkreten Fall hat das Team dann tatsächlich einen Monat lang NUR Bugs gefixt. Es gab 150 Bugs, sie haben im Monat 200 geschlossen und danach waren immer noch 50 offen (Nachzulesen hier: http://www.agileblog.org/2013/01/the-evilness-of-bugtrackers.html). Meiner Erfahrung nach führt „Bugs sofort lösen“ auf lange Sicht gesehen zu besserer Stimmung im Team (keine Bugliste im Rücken), dem Gedanken, wie man Bugs überhaupt vermeiden kann und auch zu höherer Velocity. Der letzte Punkt mag erstmal unintuitiv erscheinen, aber durch das sofortige Beheben der Bugs, fangen Teams tatsächlich eher an, sich darüber Gedanken zu machen, wie man denn generell die Qualität des Produktes erhöhen kann. Und das führt auf lange Sicht gesehen zu weniger Bugs und damit höherer Velocity. In einem konkreten Fall hat das bei mir dazu geführt, dass sich die Anzahl der Bugs/Monat halbiert hat (steht auch im oben verlinkten Artikel), während die Velocity fast um das Doppelte gestiegen ist.

  2. Die Idee, alle Bugs zwingend immer sofort zu lösen, finde ich aus Sicht der von Euch erläuterten Teamstimmung nachvollziehbar. Allerdings widerspricht das m.E. dem Ziel der Priorisierung nach Value durch den PO.
    Je nach Kontext des Produkts dürfte z.B. das von Euch mehrfach in dieser Folge bemühte Beispiel des Pixelfehlers (o.ä.) vom Product Owner als „good enough for now“ empfunden bzw. stattdessen die Konzentration auf Stories die value schaffen als wichtiger erachtet werden. Ich würde daher solche Bugs tatsächlich weiter unten ins Backlog leben (wenn ich als PO weiterhin vor habe den Bug später zu lösen). Ansonsten natürlich konsequent löschen (was leider in Backlogs viel zu selten passiert…).

    1. Da kann man sich sicherlich länger darüber streiten. Meine Meinung dazu ist, dass Bugs in die Verantwortlichkeit des Entwicklungsteams fallen. Das Team ist dafür zuständig ein technisch einwandfreies Produkt abzuliefern. Lässt du den Product Owner über die Priorität entscheiden, dann gibst die Kompetenz über die technische Qualität in Teilen an den Product Owner ab.

      Davon abgesehen, führt Bugs sammeln auch immer zu ewig langen Bug-Backlogs. Meiner Erfahrung nach kann man Bugs, die man nicht direkt behebt, in 80% aller Fälle auch direkt wieder aus dem Bugtracker löschen. Beispiel: Ein Bug, den ich 2009 bei Netbeans geöffnet habe, ist heute noch auf Status „NEW“: https://netbeans.org/bugzilla/show_bug.cgi?id=164149

  3. Sehr guter Podcast zu einem Thema, dass mich auch schon oft umgetrieben hat. Ich würde auch dazu tendieren die Bugbehebung in die Verantwortung des Teams zu geben, da sonst die Bugliste im Rücken selbst zur Demotivation führt. Außerdem wird die Behebung tendenziell teuerer, wenn man zu lange damit wartet.

    Eine Frage hätte ich nun jedoch: Wie geht ihr mit dem Commitment des Teams zum Sprintziel um, wenn es während des Sprints Bugs hagelt oder diese auch vor dem Sprint schon für diesen mitgenommen wurden. Auch ich lasse Bugs nicht schätzen, aus benannten Gründen. Auf der anderen Seite stehen aber die „wertschöpfenden Sprintziele“ aus den Stories, welche liegenbleiben würden, wenn man Bugs die Überholspur zugesteht.

    Würde das Team zum Commitement stehen, würde das bedeuten, dass Überstunden benötigt würden, um „alles“ zu schaffen. Vom „Pufferplanen“ halte ich nichts, aus den gleichen Gründen aus denen Bugs nicht geschätzt werden können. Lasst ihr also konsequent Stories vom Ende des Sprint Backlogs liegen, wenn sich die Bughebebung als sehr aufwändig herausstellt und öffnet damit die Tür zum Scheitern des Sprints (= Sprintziel nicht erreicht) oder habt ihr eine andere Lösung?

    1. „Würde das Team zum Commitement stehen, würde das bedeuten, dass Überstunden benötigt würden, um “alles” zu schaffen.“

      Korrekt. Die technische Qualität ist die Verantwortung des Entwicklungsteams, es ist damit auch seine Aufgabe eine möglichst bugfreie Software abzuliefern. Wenn es in einem Sprint auf einmal Bugs hagelt, dann sehe ich da definitiv Rede- und Handelbedarf – mindestens in der Retrospektive. Tendenziell bedeuten viele Bugs natürlich eine verringerte Velocity, es ist damit also im Interesse des gesamten Scrum Teams eine bugfreie Software herzustelen.

  4. Zum Thema Bugtracker sei folgende traurige Geschichte (von Fefe) erwähnt, der einen Bug in umatrix melden wollte:

    Der Autor hat das Bugtracking-System zugemacht. Oben stand klar und deutlich drüber: Keine Bugs für Seiten melden, die man sich kaputtkonfiguriert hat. Und die Leute haben das gesehen und trotzdem lauter solche Bugs aufgemacht. Also hat der Autor das Bugtracking-System zugemacht und jetzt ist es für alle Scheiße. Und ich bin mir fast sicher, dass keiner von denen sich im Unrecht wähnt, oder auch nur verstanden hat, dass er das gerade für alle kaputt gemacht hat.

  5. Also ich stimme euch da absolut nicht zu: Bugfxing ist wichtige Entwicklungsleistung – oft kann das Team nichts für einen Bug muss ihn aber fixen bzw. den workaround finden. Grade bei altlasten/altcode oder anderen Teams. Grade bei Produktentwicklung die sehr maintainancelastig ist, ist das oft die Hauptarbeit, warum soll das dann denen nicht bewertet und dann auch positiv angerechnet werden? Zudem nicht jeder Bug ist dringend UND wichtig, heißt der Value bzw. Ausfall des values ist vom PO zu bestimmen und nur er kann balancen wann der bug zu fixen ist. Wenn das team diese Leistung erbringen muss, braucht es auch keien PO mehr. Jeden Bug sofort zu fixen kann oft einen krassen impact auf die time to market haben.

    Wenn ein Bug nicht schätzbar ist, ist das ja auch ein Indiz für einen competence gap im team. Dann ist wohl ein Spike nötig um den Bug schätzbar zu machen. Die Velocity „leidet“ dadurch automatisch weil das Team wegen des Spike weniger Story Points commiten wird.

    Im Gegenteil wenn ich Bugs in die Sprints schmiere als Arbeitspakete ohne Value, muss ich dann beim Planning sagen: 50punkte + 3 Bugs oder was? Eine zweite Grafik für Bugs schaded aber in keinem Fall um die Dinge messbar und transparent zu machen.

    Ich glaube mit dogmatik kommt man gerade bei Bugs nicht weiter sondern ignoriert oft wichtige Leistunb bzw. priorisiert oft waste automatisch nach oben – was eigentlich zu vermeiden wäre.

  6. zum Thema Schätzen: in meinem Team werden Bugs aus Legacy Systemen mitbehoben, die zuvor NICHT als US in die Velocity eingeflossen sind. Diese lasse ich dem fixen mit SP bewerten, da sonst diese Leistung untergeht. Diese Bugs sind aber schon im Planning bekannt.

  7. Eine Idee wäre es, eine Timebox anzulegen für Bugfixing.
    Es gibt ein Bugdashboard wo – ähnlich wie das Produktbacklog – die Bugs nach Wichtigkeit sortiert sind.
    Die Bugstory – also die Ursache oder auch RCA ( Root-Cause) ist vom Team einzutragen. Die Bug-AKs währe dann die Wirkungsbehebung.(CM – Counter Messures)
    Um die Dringlichkeit festzulegen, in welcher Reihenfolge diese Bugs zu fixen sind folgt einer Risikomatrix die der Frage folgt: Welche Auswirkung hat es, wenn ich den Bug NICHT fixe.
    Funktioniert bei uns super! Nur eine Anregung zum ausprobieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert