Keiner mag Bugs, aber es ist vollkommen normal, dass welche entstehen. Oliver und Dominique sprechen in der Folge darüber, wie wir als Product Owner mit Bugs umgehen können. Dazu müssen wir natürlich erst einmal kurz darüber sprechen, was Bugs eigentlich sind.
Danach stürzen die beiden sich auf verschiedene Ansätze. Bugs können im Product Backlog eingeplant werden. Alternativ kann auch ein eigenes Bug-Backlog eingerichtet werden, an dem pro Sprint eine feste Zeit (Timebox) gearbeitet wird. Man könnte auch so arbeiten, dass ein Mitglied des Dev-Teams in einem Sprint nur Bugs abreitet. Diese verschiedenen Ansätze haben aber alle Vor- und Nachteile, weshalb unsere Diskussion in eine klare Richtung geht. Dem zugrunde liegt aber auch ein wichtiger Glaubenssatz: Defekte erzeugen durch ihre Bearbeitung einen Wert. Daher tendieren wir dazu diese einzuplanen und im Backlog sichtbar zu machen. Alternativ dazu können wir sie sofort angehen, wozu wir dann aber die entsprechenden Kapazitäten des Sprints bereit halten müssen.
Sicherlich benötigen viele Herangehensweisen auch eine Diskussion im Team. Als Product Owner können wir sie einplanen und Zeit bereitstellen. Wir können ihnen einen Wert und damit auch Sichtbarkeit geben. Als Team müssen wir aber entscheiden, wie wir die Aufgabe der Qualitätssicherung als Ganzes angehen und dem entsprechend Entscheidungen treffen. Selbst die Entscheidung bestimmte Bugs nicht zu beheben kann dann getroffen werden, damit das Product Backlog nicht zu voll wird.
Wie immer möchten wir erfahren, welche Empfehlungen für den Umgang mit Bugs du als Product Owner hast. Planst du sie ein oder werden sie neben der “normalen” Arbeit eliminiert? Wir freuen uns über deinen Kommentar, entweder hier oder auf LinkedIn.
