Mach' das Backlog leer!

Viele agile Teams führen im Regelbetrieb ein langes Backlog. Die Größe des Backlogs wirkt für viele Teams demotivierend: "Das bekommen wir nie leer. Und ständig kommt Neues hinzu."

Ein sinnvoll großes Backlog ist also das Ziel. Aber wie kommt das Team dahin?

"Fertig werden!" hat einen hohen Motivationswert. Ein nicht gepflegtes Backlog ist noch stärker demotivierend als die Arbeit des Sisyphos. Sisyphos stand immer und immer wieder vor der gleichen Aufgabe. Nimmt die Größe des Backlogs nicht ab, sondern zu, wird die Arbeit des Sisyphos mit jedem Tag größer und unbezwingbarer. Es gilt also neben der Bearbeitung von Aufgaben andere Wege zu finden, den Umfang des Backlogs zu reduzieren.

Matthias Bohlen beschreibt das in den "Fünf Mythen der heutigen Projektkultur" so:

"Den Inhalt des Backlogs betrachtet man besser als Optionen, die man ziehen kann oder auch nicht!"

Neben der Erkenntnis, dass ständig wachsende Backlogs auf das Team demotivierend wirken, führt Matthias Bohlen die betriebswirtschaftliche Komponente zu alten Backlog-Einträgen auf:

"Die Elemente im Backlog verlieren an Wert, je älter sie sind [...]"

Die Altlasten müssen also raus. Sie wirken demotivierend -- und sie haben wahrscheinlich keinen großen betriebswirtschaftlichen Wert. Backlog-Elemente können durch zwei wesentliche Optionen "verschwinden":

• Die Backlog-Einträge werden gelöscht.
• Die Backlog-Einträge werden erfolgreich bearbeitet.

Das Team sollte sich gemeinsam mit den Auftraggebern und anderen Projektbeteiligten einigen, nach welchen Regeln Backlog-Einträge gelöscht werden. Folgende Regeln funktionieren ganz gut hierfür:

1. Einträge im Backlog-Ticketsystem, die älter als ein halbes Jahr sind, werden automatisch gelöscht.
2. Backlog-Tickets, die älter als ein halbes Jahr sind, werden den Reportern zugestellt. Diese haben zu entscheiden, ob der Eintrag fortbestehen soll oder nicht.
3. In einem regelmäßigen Treffen (alle drei Monate) sichten alle Projektbeteiligten (Team-Mitglieder, Auftraggeber bzw. Auftraggeberin) die bestehenden Tickets (welche älter als ein halbes Jahr sind) und entscheiden, welche Tickets offen bleiben.
   In dieser Sitzung können auch Tickets bestimmt werden, welche einer größeren Präzisierung bedürfen. Denn häufig wird beim Diskutieren des Tickets klar, warum das Team dieses bisher nicht bearbeiten konnte -- und warum das Ticket dennoch im Sinne des Geschäftsziels sinnvoll ist.

Wenn beim Überprüfen der Tickets die Projektbeteiligten darauf geeinigt haben, dass die Anzahl der Tickets so bleiben muss, ist die Reduktion des Backlogs durch andere Maßnahmen herbeizuführen. Auch hier gibt es mehrere Optionen:

1. Verändern der Teamprozeduren, um Geschwindigkeit zu erhöhen (Erweiterung des Retrospektiven-Teams um Anforderer, gemeinsame Definition einfacherer und schnellerer Teamprozesse)
2. Vergrößerung des Teams (Brook's Law [Wikipedia] lauert schon in der Ecke: "Adding manpower to a late software project makes it later")
3. Auslagerung bestimmter Aufgaben in ein zweites Team (Kommunikationsstrukturen während der Bearbeitung und zur Sicherung der dauerhaften Software-Qualität sind zu klären.)

Wenn diese Optionen für die Projektbeteiligten doch nicht gangbar sind, sollten alle doch auf die erste Option, das Löschen von Backlog-Einträgen, zurückkommen. 

Wohl an - befreit Euch und Euer Backlog im Regelbetrieb von belastenden Altlasten!