0 Punkte
in Agiles Projektmanagement von
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)?

2 Antworten

0 Punkte
von
In der Tat ist das Schätzen von Bugs eine heikle Angelegenheiten. 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.
von
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.
von
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.
0 Punkte
von
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.
Teamprove Wissen – die OnlineCommunity für agile Unternehmen

Wir bieten agilen Einsteigern und Experten eine Frage-Antwort-Plattform zum Austausch mit Gleichgesinnten – von Scrum über Unternehmenskultur & Leadership bis hin zu Innovationsmanagement.
...