IMHO: Bugs für die Velocity? Gift für die Produktivität!

Immer wieder werde ich als Agiler Coach mit der Frage konfrontiert, ob – bzw. besser mit dem Wunsch, das - Bugs mit Story Points geschätzt werden sollten, damit sichtbar wird, dass das Team ja fleißig ist und die Velocity des Sprints nicht gefährdet wird.

Meistens kommt das auf, wenn es viele Bugs im System gibt und das Team unzufrieden mit der Velocity ist. Die Lösung ist also: Bugs mit Story Points zu schätzen, um die Velocity nicht absinken zu lassen.

In meinem Fall waren es auch jeweils Teams, die für einen externen Kunden arbeiten, der natürlich auch die Entwicklung der Velocity im Blick hat (wie sinnvoll dieses Konstrukt ist, wird an einer anderen Stelle diskutiert ;) ).

Also: Story Points an die Bugs und alle sind glücklich? Nein, denn… 

Ja, das ist eine harte Aussage, aber ich erkläre, warum ich davon überzeugt bin, dass Bugs keine Story Points verdient haben.

Vorher ist noch wichtig, darauf zu gucken, was genau ein Bug eigentlich ist:

Wikipedia:

[Ein Bug] ... tritt auf, wenn der Programmierer eine bestimmte Festlegung der Spezifikation nicht oder falsch umgesetzt hat, oder wenn die Laufzeitumgebung fehlerhaft bzw. anders als erwartet arbeitet. Weiterhin können auch Unvollständigkeit, Ungenauigkeit oder Mehrdeutigkeiten in der Spezifikation des Programms zu „Fehlern“ führen.

Man kann hier lesen, dass es DREI verschiedene Gründe haben kann, von einem Bug zu sprechen :

• Fehler eines Programmierers
• Unerwartete Verhalten auf einer Laufzeitumgebung ("Bei mir läuft's"-Syndrom)
• Fehler in der Spezifikation

Im Falle, dass das Team für einen Kunden arbeitet, der selbst die Storys schreibt und abnimmt, bin ich der Meinung, dass viele der "Bugs" gar keine Bugs sind, sondern auf Fehler in der Spezifikation zurückzuführen sind. Dann spricht man klassischer Weise von einem "Change Request", der eventuell - je nach Vertragsart - aufwändig verhandelt werden muss.

Ziel sollte sein, dass diese "Bugs" nicht als solche ins Backlog kommen, sondern als geschätzte Storys oder Tasks ganz normal in einen Sprint eingeplant werden. Denn sie beschreiben eine neue bzw. ursprünglich schlecht beschriebene Funktionalität und fügen dem Produkt einen Wert zu.
Hier ist das Team gefordert, diese Art von Bugs zu identifizieren und sich diese nicht als Bugs "unterschieben" zu lassen.

Die beiden anderen Gründe (Programmierer-/ oder Laufzeitumgebungsfehler) liegen im Verantwortungsbereich des Teams und sollten demnach nicht dazu führen, dass sich das Team damit belohnt, selbst gemachte Fehler zu beheben.

Es mag etwas hart klingen, aber Bugs im Sprint müssen meiner Meinung nach weh tun, damit alle daran arbeiten, dass möglichst immer weniger auftauchen . Ein Bug fügt dem Produkt keinen Wert hinzu, sondern sorgt dafür, dass ein versprochener Wert tatsächlich zur Verfügung steht. Die Story Points für die Funktionalität wurden ja längst "verbrannt"; wenn wir dem Bug noch einmal Story Points geben, erhöhen wir die Gesamtanzahl der Story Points, die ja auch den Wert widerspiegeln, die eine Story einem Produkt hinzufügen. Das ist faktisch falsch.

Bugs haben Gründe - daran muss gearbeitet werden!

Wenn die im Sprint auftauchenden oder in den Sprint eingeplanten Bugs das Team immer wieder aus dem Tritt bringen und keine vorhersagbare Velocity zulassen, muss das Team gemeinsam z.B. mit dem Scrum Master an einer Lösung arbeiten - besseres Testing, Pair-Programming, Story-Swarming etc. könnten da Besserung bringen. Evtl. wird aber auch die Laufzeitumgebung von Dritten verändert/gewartet – dann müssen bessere Absprachen her.

Oder es fehlt Domänen-Wissen - dann muss es Weiterbildung geben. Wenn das Team dauernd aus anderen Personen besteht, ... Ihr seht schon, es gibt viele Gründe, warum vermehrt Bugs auftreten können.

Und nie ist eine gute Lösung, Bugs mit Story Points zu versehen, denn dann bist du ja zufrieden damit. Bugs abzuarbeiten zahlt dann auf deine Velocity ein und das vermittelt ein falsches Gefühl von Produktivität!

Besser: Prüfe, ob du nicht doch einen Change-Request und damit eine Story/einen Task hast und arbeite an den Gründen der echten Bugs. Dein Scrum Master hilft dir bestimmt gerne! :)

Andere Meinung oder gleiche Erfahrungen gesammelt? Tweet an @Zawenn