am 19. Juli 2010
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.
