Facebook
Twitter
Google+
Kommentare
10
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

Viehzeug in Scrum – Bugs vom Product Backlog trennen oder nicht?

Eine Diskussion, die ich inzwischen schon ziemlich oft mit verschiedenen Scrum Teams geführt habe, dreht sich um die Frage, ob und was Bugs im Product Backlog verloren haben. Die gewollt offene Auslegungsweise von Scrum lässt hier viel Interpretationsspielraum und tatsächlich regeln das viele Teams anders.

Oftmals wird das Thema relativ einfach damit unter den Tisch gekehrt, dass das Projekt ja ohnehin keine Bugs haben sollte, man achtet ja auf Qualität, fehlerhafte Softwareinkremente werden vom Product Owner gemäß der Akzeptanzkriterien nicht abgenommen und ohnehin ist man ja agil und geht flexibel mit auftretenden Problemen um. In der Theorie oder reinen Innovationsprojekten mag das ja durchaus Sinn machen und funktionieren, in größeren Projekten oder gar im Produktiveinsatz laufenden Systemen ist die Frage allerdings schon nicht mehr so einfach abzuhaken.

Über den Einsatz von Scrum in Wartungsprojekten kann man endlos diskutieren, aber auch hier kann eine gesunde Adaption des Frameworks gut funktionieren. Gehen wir aber nun von dem Fall aus, dass ein Projekt fleißig entwickelt wird. Treten während der Implementierung – innerhalb eines Sprints – Probleme auf, die unmittelbar durch diese Implementierung hervorgerufen wurden, sollten sie auch direkt gefixt werden. Sie sollten dann zwar als Impediment auftauchen, gehören aber noch unmittelbar zu den mit dieser Implementierung verbundenen Aufwänden.
Gehen wir weiter, das Projekt kommt nun in einem Stadium, in dem es in den Produktivbetrieb übergeht. Es ist also live, das Product Backlog enthält aber nach wie vor einige Anforderungen, welche nun nach und nach umgesetzt werden.

Ab dem Zeitpunkt, ab dem das Projekt im Produktiveinsatz ist, werden unweigerlich Bugs auffallen, welche durch User berichtet werden oder auch dem Team selber auffallen. Was also mit diesen eintreffenden Bugs machen? Sofortiges Bearbeiten dieser Bugs wäre ein Bruch mit der Definition eines Sprints: das Team wäre nicht mehr durch Einflüsse von außen geschützt und der Sprint gefährdet. Natürlich können wir aber, wenn das System komplett steht, nicht einfach sagen “Ja klar, aber wir können das jetzt nicht fixen, das würde das Sprintziel gefährden”.

Es muss also zuerst abgewogen werden, ob ein Bug so kritisch ist, dass er unmittelbar behoben werden muss. Es liegt in der Sache der Natur, dass dies eine sehr subjektive Auslegung ist und jede Partei die Sache anders sehen wird. An dieser Stelle ist es entscheidend, dass Product Owner und Scrum Master eine gute Kommunikation miteinander pflegen und gemeinsam zu einem möglichst guten Ergebnis kommen. In unserem Team läuft es so, dass es für solche “Blocker Bugs” eine extra “Bugpipe” oberhalb der ersten Story auf dem Taskboard existiert, in welcher solche kritischen Bugs an den anderen Stories “vorbeigeschoben” werden können. Hierfür qualifizieren sich aber tatsächlich nur kritische Bugs, welche etwa für einen Systemstillstand sorgen (können) oder die Akzeptanz eines Features maßgeblich gefährden. Trotz allem sollte aber trotzdem berücksichtigt werden, dass Tasks, an denen die Entwickler gerade arbeiten, abgeschlossen werden sollten, denn die Unterbrechung von Tasks gilt als Verschwendung. Da Tasks aber nicht länger als einen Tag dauern sollte, ist dies in der Regel auch kein Problem.

Was ist nun aber mit Bugs, welche nicht so kritisch sind und irgendwie festgehalten werden müssen? Kommen die nun ins Backlog? Werden sie seperat gepflegt? Die Anzahl an Möglichkeiten deckt sich vermutlich mit der Anzahl an Scrum Teams. Manche Teams machen es so, dass Bugs tatsächlich auch als Anforderung formuliert werden, somit also auch wirklich im eigentlichen Product Backlog landen. Das mag bei vielen Teams funktionieren. Meine persönliche Erfahrung ist aber, dass es, durch die komplizierte Umformulierung eines Bugs in eine Anforderung, dem Team oft schwer fiel, auf dem ersten Blick aus dieser Anforderung das eigentliche Problem herauszulesen. Zudem klagte unser Product Owner über ein immer weiter wachsendes Backlog. Das war nicht nur durch auftretende Bugs der Fall, sondern ist in einem System, das sich in ständiger Weiterentwicklung befindet, nicht unüblich, da immer wieder neue Anforderungen eintreffen.

Wir haben uns in unserem Fall dazu entschieden, Bugs in einem seperaten “Buglog” zu führen. Für den Product Owner hatte das mehrere Vorteile: er konnte Anforderungen und Bugs seperat priorisieren und die Übersicht innerhalb der getrennten Logs war besser. Kritisch zu betrachten ist dabei allerdings die Tatsache, dass mangels eines kombinierten Backlogs, auch eine “Produktvision” fehlt. Es gibt keinen einfachen Gesamtüberblick über die unmittelbar anstehenden Arbeiten.

Für uns haben wir das ganze etwas weiter adaptiert: das Backlog ist ohnehin in mehrere Bereiche segmentiert, wobei der Kopf des Backlogs immer den Teil widerspiegelt, welcher als nächstes umgesetzt wird. Wir haben bei uns nun ein lebendes Backlog. Das bedeutet, dass es prinzipiell nur Anforderungen enthält. Kurz vor dem Beginn eines neuen Sprints, also der Sprintplanung, wird durch den Product Owner beim Backlog Refinement auch das Buglog überprüft. An dieser Stelle werden Bugs, welche unmittelbar in den nächsten Sprint einfließen sollen, ins Backlog übernommen. Das heißt also, der Kopf des Backlogs besteht kurz vor Sprintbeginn dann tatsächlich aus Bugs und Anforderungen.

Auch hier gilt wieder: es gibt keine absolute Wahrheit! Der Prozess funktioniert so für unser Team inzwischen sehr gut und half dem Product Owner auch, seine Arbeit zu erleichtern, denn letztlich ist er es, der mit dem Backlog arbeiten muss und die Hoheit über selbiges hat. Trotzdem darf man nicht vergessen, dass auf diese Weise eine “globale Produktvision” verloren geht. Es steht also in der Verantwortung des Product Owners, diese dennoch zu pflegen und dem Team, als auch nach außen vermitteln zu können!

Interessant ist an dieser Stelle auch das Thema “Schätzungen von Bugs”, welches ich aber hier gezielt außen vor lassen möchte und vielleicht mal in einem weiteren Artikel behandle. Mit diesem Artikel wollte ich einfach mal auf meine Sicht der Dinge zu dem Thema eingehen und freue mich natürlich darüber, wenn andere aus ihrer Scrum Praxis berichten.

Über den Autor

Sebastian Bauer

Auch ich hasse manchmal PHP, und doch liebe ich es. Aber geht es uns nicht allen so? Darüberhinaus beschäftige ich mich intensiv mit Android, Webentwicklung und Scrum und philosophiere auch gerne über Programmierparadigmen.
Kommentare

10 Comments

  1. Bei uns gibt es externe Tester, die nach dem Sprintabschluß die Software testen. Die gemeldeten Bugs lösen sich gelegentlich in Wohlgefallen auf, da diese „Bugs“ im folgenden Sprint von selbst gelöst werden.
    Ansonsten gibt es die Richtlinie 10% der Zeit für Bugs aufzuwenden und dies selbst zu entscheiden, da alle Bugs sowieso behoben werden müssen.

    Persönlich finde ich diesen Weg nicht besonders schön, aber besser als später 2-3 Sprints lang nur Bugs zu lösen ist es allemal.

    Die Idee des Buglogs finde ich gut.

    Reply
  2. @Norbert: erstmal danke für den Einblick, wie es bei euch läuft. Für jeden Sprint auch eine Bugfixing Timebox vorzusehen finde ich gar nicht mal so falsch. Es muss letztlich ja im entsprechenden Team funktionieren.

    Aber ich gebe dir Recht, dass es allemal besser ist, als einen riesen Berg Bugs anzuhäufen und dann 2-3 Sprints nur Bugs zu fixen. Das ist zum einen für die Entwickler meist demotivierend (weil Bugs oft viel Zeit kosten können, ohne das Gefühl zu geben, produktiv etwas geleistet zu haben) und verhindert vor allem, dass ein „echtes“ Produktinkrement geliefert werden kann.

    Reply
  3. Ich bin Anhänger der „Bugs sofort fixen“ Fraktion, das erspart einem das Führen von Buglisten / Buglogs / etc.

    Das Argument „Bugs gefährden das Sprintziel“ finde ich stark fragwürdig. Bugs entstehen häufig durch unsorgfältige Arbeit und eine stabile, bugfreie Software ist besser als eine, die konstant Features rauswirft. Der Fokus sollte also tatsächlich auf Bugs beheben liegen, sofern welche da sind. Sicherlich kommt es dann auch mal zu Sprints die von Bugs überflutet werden, aber spätestens dann sollte man sich überlegen, ob die Arbeitsweisen noch passen, ob man genug Pair Programming, TDD, o.ä. macht

    Reply
  4. @Dominik: prinzipiell gebe ich dir Recht und ich vermeide es auch lieber, Bugs aufzuschieben. In Projekten, die aber noch sehr alten Legacy-Code haben, der nicht durch Tests abgedeckt ist usw ist es z.T. aber nicht unbedingt zu rechtfertigen, kleine und alte Bugs zu fixen und aktuellen Tasks vorzuziehen.

    Bugs so schnell fixen wie möglich, ist generell schön und gut, funktioniert einfach in manchen Geschäftsumfeldern leider nicht, und wenn es nur das Management ist, das es nicht akzeptabel findet, aktuelle Feature-Entwicklungen für alte Bugs zu gefährden.

    Reply
  5. @Dominik ich schaue in meine Glaskugel und erkenne das du kein Entwickler im eigentliche sinne bist 😉
    Dies kann wohl nur die Ansicht eines Projektmanagers sein oder einer der schon lange nicht mehr Produktiv entwickelt hat.
    Desweiteren möchte ich @Sebastian mit dem Bughandling recht geben.

    Reply
  6. @Sebastian: Dann ist die Frage, ob beim Management noch nicht angekommen ist, dass stabile, bugfreie Software die bessere ist.

    @tomlose: Da hat deine Glaskugel leider versagt, ich bin sogar ausgebildeter Fachinformatiker Anwendungsentwicklung

    Reply
  7. @Dominik: definitiv 😉 Das Problem hierbei ist, dass man diese Punkte zwar immer wieder aktiv herantragen kann und klar vor den Konsequenzen warnen kann, aber Einfluss hat man darauf leider keinen.

    Reply
  8. Ein Artikel über „Schätzungen von Bugs“ würde mich sehr interessieren. Wir sind erst vor kurzem auf Scrum umgestiegen und tun uns noch recht schwer auftretende Bugs richtig zu verwalten und ins Backlog einzupflegen. In den Planungsmeetings hört man oft die Aussage „Das ist unschätzbar“, was uns ja nicht wirklich weiterhilft.

    Das Buglog ist eine gute Idee, mir ist jedoch die Handhabung noch nicht ganz klar. Wie genau sind die Bugs in dem Buglog bei euch aufgeführt? Stehen da schon grobe Schätzungen bzw. Priorisierungen drin oder wird das erst in den Planungsmeetings besprochen? Ich stelle es mir ziemlich schwierig für den Product Owner vor, hier präzise priorisieren zu können.
    Konrekt: Angenommen während des nächsten Sprints soll der Release eines Produkts fertiggemacht werden. In dem Buglog haben sich jetzt allerdings in den letzten Tagen einige Bugs angehäuft, die zwar nicht kritisch, aber dennoch auch nicht gerade trivial zu lösen sind. Die Anzahl der Bugs könnte den Release gefährden, was dem Product Owner erst in dem Planungsmeeting schmerzlich bewußt wird. Daher könnte der Product Owner jetzt den Release-Termin natürlich nach hinten verschieben, aber das kann ja auch nicht in jedem Fall realisiert werden. Gibt es bei euch eventl. noch mehr Eskalationsstufen was Bugs betrifft?

    Reply
  9. Hallo Frank,

    wenn der PO im Planungsmeeting festestellt dass er zuviele Bugs für das Release hat dann hat er, wenn er diese Vorgehensweise wählt, schlicht einen Fehler gemacht.
    Ganz generell: Wenn man wegen zu vieler Bugs sein Release gefährdet sieht liegt das Problem nicht darin wie man mit Bugs umgeht, sondern wie man Software entwickelt.

    Gruß,
    Christoph

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen