Viele Teams betreiben ihr Bugtracking mithilfe von Tools wie Jira oder Bugzilla. Diese Tools haben zwei Funktionen: Zum einen die Meldung von Bugs an das Team durch Tester oder Anwender und zum anderen das Tracking selbst. Als hilfreiche Ergänzung möchte ich an dieser Stelle das physikalische Taskboard ins Spiel bringen, denn werden Bugs auf einer solchen Tafel mit aufgeführt, erhöht dies die Transparenz und Übersichtlichkeit. Wichtig ist hierbei, jeden Bug seinem Impact entsprechend einer Klasse zuzuordnen. Prinzipiell sollte gelten: Nur wirklich schwerwiegende Bugs, die das Gesamtsystem gefährden, werden mit oberster Priorität auf einem Post-it in einer eigenen Farbe (z.B. rot :)) an das Taskboard geheftet und im laufenden Sprint bearbeitet. Kosmetische oder niedrig priorisierte Bugs können später behoben werden, um den Fokus im geschützten Sprint nicht zu verlieren. Sie wandern ins Backlog und werden im Zuge der folgenden Sprints (evtl. auf orangenen Post-its) je nach Dringlichkeit bearbeitet. Wo immer es Sinn macht, kann man darüber nachdenken, inwieweit man die Beschreibung eines Bugs in eine User Story – also etwas Positives – umformulieren kann.
Die Fertigstellung von Features kann nicht nur durch Bugs, sondern durch verschiedenste Blocker (Impediments) behindert werden. Das Impediment Backlog enthält bekanntlich verschiedenste Arten von Blockern. Betrifft ein solches Hindernis direkt einen Task oder eine Story, so kann es auf einem kleinen roten Post-it an die entsprechende Karte geheftet werden: dies erhöht die Transparenz und stellt einen direkten Bezug her.
Es empfiehlt sich, am Taskboard alle Tasks, die dem Sprint Planning II entstammen, auf gleichfarbigen (z.B. gelben) Post-its festzuhalten. Kommen im Rahmen der Umsetzung neue Tasks hinzu, so können diese in Form andersfarbiger Post-its (z.B. blau) angeheftet werden. Somit ist auf den ersten Blick erkennbar, inwieweit neue, im Sprint Planning II nicht bedachte Tasks entstanden sind. Diese Informationen können später im Rahmen der Retrospektiven verwendet werden und zur Ableitung von Verbesserungsmaßnahmen beitragen.
Ein derart farblich codiertes Taskboard kann auf einen Blick Gründe für eventuell nicht fertiggestellte Features liefern, darüber hinaus verschafft es einem allein durch die Farbgebung einen Eindruck vom aktuellen „Gesundheitszustand“ des Projekts.
