Aus dem Manifest für agile Softwareentwicklung:
„Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: […]
Reagieren auf Veränderung mehr als das Befolgen eines Plans“
Der Backlog oder die Warteschleife
Wer sich mit agilen Methoden auseinandersetzt, der stolpert recht schnell über das sogenannte Backlog. Der Begriff Backlog bezeichnet im Allgemeinen nichts anderes als eine Menge an Arbeit in Form von Aufträgen, die sich angesammelt hat und darauf wartet „abgevespert“ zu werden. Vereinfacht ausgedrückt: es ist eine „To-Do-Liste“ mit offenen Punkten. Oder anders gesagt, es sind Arbeitsaufträge in einer Warteschleife.
In Scrum wird zum Beispiel zwischen dem Produkt- oder Productbacklog und dem Sprintbacklog unterschieden. Der Produktbacklog bezeichnet die Gesamtheit der gesammelten Anforderungen, die umgesetzt werden sollen. Während der Sprintbacklog alle diejenigen Anforderungen umfasst, die in dem kommenden Sprint erledigt werden sollen. Zusätzlich enthält der Sprint Backlog weitere Details, die das Team benötigt, um das Sprint-Ziel zu erreichen. Der Sprint entspricht dem aktuellen Planungszeitraum. Zur Erinnerung, agile Methoden zeichnen sich durch die Bank durch iterativ-inkrementelles Vorgehen aus. D. h. dass immer nur für eine kurze überschaubare Periode – zumeist maximal für einen Zeitraum von vier Wochen – detailliert oder verfeinert geplant wird, was zu tun ist.
Der Backlog – ein lebendiges Dokument
Anders als bei einem klassischen Projektplan gibt es keine Meilensteine und terminierten Aufgaben. Auch wenn bei längeren agilen Projekten gelegentlich der Begriff „Roadmap“ und von Releaseplanung die Rede ist, sind es auch hier nur grobe zeitliche Eckpunkte, die der Koordination dienen. Aber nicht, wie mensch aus dem klassischen Projektmanagement kennt, fest zementierte Meilensteine, zu denen fest gefügte Arbeitspakete abgeschlossen sein müssen.
Diese Liste von Anforderungen in der Warteschleife – also der Backlog – ist ein extrem lebendiges Dokument. Der Backlog ist im permanenten Fluss und ständiger Veränderung unterzogen. Immer wieder kommen neue Elemente dazu, bestehende Elemente werden gestrichen, neu bewertet, Prioritäten ändern sich nach oben und dann wieder nach unten. Die Anforderungen in der Warteliste passen sich an die sich verändernden Rahmenbedingungen im Entwicklungsprozess an. Im Vergleich zur klassischen Planung, bei der im Idealfall bereits zum Beginn alle Arbeitspakete klar und detailliert festgelegt und terminiert werden, erfolgt die Verfeinerung und die Festlegung der Details im Backlog im laufenden Prozess. Der Schwerpunkt bei der Verfeinerung liegt dabei immer bei den am höchsten bewerteten Aufgaben im Backlog, wobei die Priorisierung vor jeder Planungsphase neu betrachtet und an die Veränderungen angepasst wird.
Aufgaben aus dem Backlog ziehen oder das Prinzip Pull statt Push
Bleiben wir bei Scrum, ist der Produktbacklog die übergeordnete „Warteschleife“. Während der Sprintplanung zieht sich hier das Team die entsprechend priorisierten und verfeinerten Anforderungen in den Sprintbacklog, und zwar in dem Umfang, wie das Team meint, die Menge auch tatsächlich in der Sprintdauer leisten zu können. Verantwortlich dafür, dass der Produktbacklog sauber gepflegt und inhaltlich auf dem neuesten Stand ist, ist übrigens der Produkteigentümer. Also der derjenige, der die Interessen des Auftraggebers im Team vertritt. Dass nur mal am Rande noch mal zu Erinnerung ins Spiel gebracht. Zum sogenannten Backlog-Grooming, also der Pflege des Backlogs, gehört übrigens auch die Aufwandsschätzung 😉
Beim Sprintbacklog funktioniert es ähnlich: Die Teammitglieder ziehen sich ihre aktuelle Aufgabe, die sie bearbeiten wollen, aus dem Sprintbacklog. Hat ein Teammitglied seine aktuelle Aufgabe erledigt, kennzeichnet er sie entsprechend. Auf einer Scrum- oder Kanbantafel wandert diese Aufgabe dann in aller Regel in die Spalte „Erledigt“. Anschließend nimmt sich das Teammitglied die nächste, noch offene Aufgabe auf der Liste und setzt diese auf „In Bearbeitung“, bis auch diese „Erledigt“ ist. Der Prozess wiederholt sich, bis der Sprintbacklog leer ist oder der Planungszeitraum zu Ende ist und neu geplant wird.
Aufgaben werde also nicht einfach zugewiesen, sondern es wird ein „Aufgabenpool“ gebildet. Und jeder wirkt eigenständig daran mit, die Aufgaben abzuarbeiten. Soll heißen, es wird nicht zugewiesen, sondern abgeholt. Die Rede ist von Pull statt Push.
Wie lässt sich das Prinzip in den Alltag übertragen?
Die Rede war oben mehrfach von Scrum. Nur arbeiten wir ja nicht alle und immer in Projekten und nicht jedes Projekt ist auch tatsächlich für Scrum geeignet. Das beschriebene Prinzip des Backlogs findet sich – wie eingangs erwähnt – auch in anderen agilen Methoden wieder. Zum Beispiel in Kanban. Das Ganze kann etwas variieren. Aber das Grundprinzip ist ähnlich: Pull statt Push. Dem gleichen Prinzip folgt übrigens auch Lean Coffee, dass wir wie auch Personal Kanban bereits hier im Blog vorgestellt haben.
In die Praxis umgesetzt: Warum nicht mal gemeinsam mit dem Team sammeln, welche Themen zu erledigen sind, und einmal wöchentlich gemeinsam priorisieren, was in der Woche gemacht werden soll? Am Ende der Woche schaut mensch sich gemeinsam an, was alles erledigt wurde. Sprich Zeit für eine Retrospektive. Ziel erreicht? Wenn ja, warum? Wenn nein, warum nicht? Was ist gut gelaufen, was weniger gut? Haben sich Prioritäten verändert? Zwingen neue Erkenntnisse dazu, die Liste zu ergänzen, Aufgaben zu streichen oder fortzuschreiben? Personal Kanban kann in diesem Zusammenhang ein Einstieg sein.
Schon probiert? Wie sind Ihre Erfahrungen? Was würden Sie empfehlen? Schreiben Sie uns doch einfach eine E-Mail oder kommentieren Sie hier im Blog. Gerne können Sie auch unsere Facebook-Gruppe nutzen. Dafür ist sie da. Teilen Sie Ihre Erkenntnisse mit uns und mit anderen.
Agile Verwaltung 
