Im Backlog Refinement Meeting sollen sich die Teammitglieder die Items anschauen die in zukünftigen Sprints umgesetzt werden müssen. Dazu gehören oft auch Bugs. Um im Planning zu wissen wieviele Items im Sprint reinpassen, sollten auch Bugs eine Schätzung haben. Oder nicht? Ist das Schätzen von Bugfixes wirtschaftlich? Ist das Schätzen von Bugs nicht genauso aufwändig wie das Lösen selbst (weil man ja irgendwie die Ursache des Problems gefunden haben muss, und das ist in der Regel das Aufwändigste)?
4 Antworten
Wofür schätzen wir (ganz kurz gefasst)?
Schätzungen sollen uns helfen bei der Einschätzung, was wir schaffen, in Scrum also in einem Sprint. Zusätzlich kann man sie verwenden, um abzuschätzen, wie lange durchschnittlich die Bearbeitung großer Themen dauert.
Kann man Bugs schätzen?
Ich stimme den anderen Antworten zu, dass man Bugs viel schwieriger abschätzen kann, da die Analyse ob und falls ja was zu tun ist, länger dauert als die Umsetzung. Das bedeutet aber nicht, dass man mehr Zeit für die Schätzung aufwenden muss. Man könnte z.B. auch die Durchschnittsgröße vorheriger Bugs in dieser Domain oder in diesem technischen Bereich schätzen und den einfach nehmen. Damit ist es wirtschaftlich, da die Schätzung kaum Zeit nimmt (die Wahrscheinlichkeit, dass man größer drüber oder drunter liegt aber deutlich größer als bei anderen Backlog Items).
Kann man die Velocity interpretieren, wenn man Bugs schätzt?
Typischerweise erwartet man mindestens eine gleichbleibende Velocity (nicht zu verwechseln mit einem gleichbleibendem Mehrwert - dieser hängt an dem geschätzten Mehrwert einer Story, nicht an der geschätzten Komplexität/Aufwand/Risiko einer Umsetzung). Schätzt man Bugs nicht, erwartet man eine fallende Velocity, wenn immer mehr Bugs reinkommen und kümmert sich dann darum. Steigt die Velocity könnte es daran liegen, dass man weniger Bugs bearbeiten muss.
Schätzt man Bugs mit, dann könnte es sein, dass die Velocity gleich bleibt, nur der Anteil an Bugs variiert. Um die Bugs zu interpretieren, muss man die Summe der Bugs also getrennt betrachten, was kein technisches oder methodisches Problem sein sollte.
Würde ich Bugs im Nachhinein 'Schätzen'?
Falls wir Bugs im Nachhinein Schätzen, dann gleicht diese Schätzung eher Messungen, da je nach Aufmerksamkeit man relativ exakt sagen kann, wie lange eine Umsetzung gedauert hat / wie komplex sie war / wie viel Aufwand es war.
Meine persönliche Erfahrung ist hier, dass wir hier dazu neigen im Kopf die genauen Stunden in Story Points umzurechnen (Pi mal Daumen). Das können wir bei den anderen Backlog Items nicht. Das kann dazu führen, dass wir bei anderen Backlog Items auch den bekannten Aufwand in Stunden versuchen abzuschätzen und diese dann wieder in Story Points umrechnen. Da wir bei diesen Backlog Items aber vieles nicht wissen, müssen wir üblicherweise deutlich mehr tun, als das im Voraus Bekannte. Ich habe hier die Erfahrung gemacht, dass die im Nachhinein geschätzten Bugs im Verhältnis zu hoch geschätzt werden. Man kann dies abmildern mit dem ständigen Vergleich mit z.B. Referenzstories. Trotzdem ist die Art des Schätzens dann eine andere, da ich beim einen etwas Unbekanntes Vergleiche und bei Bugs einen bekannten Aufwand.
Ich halte dies nicht für ein großes Problem, würde aber trotzdem nach Möglichkeit dazu tendieren, die Arbeit an Bugs anderweitig zu sammeln (z.B. mit Strichen an einem Board für jede angefangene halbe Stunde bei Arbeit an Bugs <-- wenig Aufwand, (ausreichend) hohe Präzision).
In der Tat ist das Schätzen von Bugs eine heikle Angelegenheit. Aus genau den Gründen, die Giancarlo oben genannt hat. Was bei meinen Projekten oft der Fall ist, dass wir wenn wir nicht schätzen, im Nachgang Story Points vergeben für den tatsächlichen Aufwand. Das hilft insbesondere dafür im Nachgang zu bewerten, wieviel % des Sprints für Fehlerbehebung aufgewendet wurde. Tendenziell hilft dies bei der Planung zukünftiger Sprints (insbesondere wenn die Fehlerrate nicht zu sehr schwankt). Und andererseits ist es ein guter Indikator für die Qualität des Produktes, aber auch des Prozesses. In Continuous Deployment Umgebungen zeigt er direkt einen Zusammenhang zur Produktqualität. In Non-Continuous Deployment Umgebungen ist es ein guter Hinweis, wo Schwächen im Entwicklungsprozess sind. Z.B. wenn trotz aufwändiger Unit-Tests, Mockup-Tests usw. sich in der Integration herausstellt, dass beim E2E-Test unerwartete Fehler auftreten. In Retrospektiven kann der Fokus dann gezielt darauf gelenkt werden.
In meinem aktuellen Projekt beschätzen wir die Defects bereits vor Behebung mit Storypoints. Das gelingt natürlich mehr oder weniger gut (siehe Gründe des Fragestellers), ist aber immer noch besser als gar nicht mit ihnen zu planen.
In meinem aktuellen Projekt beschätzen wir die Defects bereits vor Behebung mit Storypoints. Das gelingt natürlich mehr oder weniger gut (siehe Gründe des Fragestellers), ist aber immer noch besser als gar nicht mit ihnen zu planen.
Danke Markus für deine Antwort! Ist es dann nicht besser die Zeit die tatsächlich für Bugfixing verwendet wurde aufzunehmen, wenn ich nur wissen möchte wieviel Zeit ich pro Sprint um Bugs zu fixen verwende? Schätzungen sind ja per Definition ungenau und auch noch Aufwändig.
Ja richtig, das Schätzen ist ungenau. Deswegen machen wir da auch keinen großen Aufwand draus, sondern sagen den Teams einfach: 'Put some story points on it'. Das macht dann der Entwickler, der den Bug auch fixed innerhalb von Sekunden, da die Diskussion WAS da eigentlich schief gegangen ist bereits erfolgt ist.
Nun, inwiefern es wirtschaftlich ist kommt denke ich auch etwas darauf an, wie viel Zeit man in das schätzen investiert. Bugfixes zu schätzen ist schwieriger als User Stories. Es erfordert mehr ein Verständnis von dem, was bereits im Code passiert ist und User Stories, zielen mehr darauf ab, neuen Code zu produzieren und in bestehenden einzubetten. Auch einen Bug als solchen zu identifizieren kann Zeit kosten. Womöglich war es auch ein Fehler in der Spezifikation und man könnte daraus einen Change Request machen, der dann auch leichter zu schätzen wäre. Bugfixes sind eine Suche und wie wirtschaftlich es ist kann aus meiner Sicht also stark davon abhängen, wie gut die Entwickler den Code bereits kennen. Ich persönlich bin auch kein Freund davon Bugs mit Story Points zu schätzen. Entscheidet man sich dafür könnten Tage, Stunden oder auch T-shirt-Größen helfen, um ein besseres Gefühl für die Sprintplanung zu haben, man muss ja irgendwie einplanen wie viel Zeit neben dem Bug für andere items bleibt. Einem Bug Story Points zuzuordnen, verfälscht aber irgendwie die Velocity und erzeugt ein Gefühl von, wir haben so viel Wert gestiftet. Ein Bug ist aber ein Fehler einer Funktion, für die es bereits Story Points gab und möchte ich wirklich einen Fehler mit einer steigenden Velocity belohnen? Was wirklich wirtschaftlich wäre, wäre für mich also mehr die Ursachen für die Bugs zu finden und zu beheben. Das könnten zu häufige personelle Veränderungen sein oder nicht ausreichendes Domänenwissen. Schulungen, Story-Swarming, besseres Testing oder Pair-Programming könnten zum Beispiel entsprechende Ansätze sein.
Wie immer, es kommt auf den Kontext an.
In den teams mit denen ich gearbeitet habe hat man auch Bugfixing Aufgaben geschätzt. Ein einfach zu behebender Bug ist schnell geschätzt, ein Kniffliger oft überhaupt nicht schätzbar. Darum arbeiten wir mit
- Blitzanalysen, wenn unser Support einen Bug nicht reproduzieren kann. Dabei investiert der Entwickler maximal 30 Minuten und zeitnah und oft sieht er mit wenigen Blicken wie heftig der Bug ist.
- Analysestories: Bugs die man im Refinement nicht schätzen kann weil die Ursache auch für Entwickler unklar ist wird über eine storypointbegrenzte Userstory analysiert. Wenn man den Bug dann auch noch schnell fixen kann, dann wird das natürlich gleich gemacht. Erfordert die Analyse oder der Bugfix mehr Zeit als die vereinbarten (1, 2?) Story Points () dann wird die Story abgebrochen und das Zwischenergebnis mitgeteilt. Die Story Points werden dabei einmalig als Faustregel festgelegt. Bei uns 2.
Danke Jürgen für deine Antwort! Das mit den Blitzanalysen finde ich spannend, gerade im Support. Die Analysestories machen mir etwas Angst. Eine Story müsste eigentlich etwas liefern was dem Kunden hilft. Und ja, mit viel Vorstellungskraft, kann eine Schätzung auch als "Mehrwert" sehen, was der Kunde aber wirklich braucht ist eine Lösung. Vielleicht könnte das Ergebnis auch erreicht werden indem nicht die "Analysestory" sondern einfach nur der Bug bearbeitet wird (mit dem Ziel es zu lösen) und wenn eine gewisse Frist überschritten wird, dann wird es entweder abgebrochen (und Zwischenergebnis mitgeteilt) oder weitergemacht und Lösung geliefert.