Backlog-Management

Ziel

Das Backlog dient dazu, die verbleibende Arbeit zu erfassen, zu verfolgen und zu priorisieren. Es antwortet auf eine dauerhafte Lage: Das Volumen der zu leistenden Arbeit übersteigt die Kapazität, sie zu leisten, und die Abwägung muss deshalb laufend neu getroffen werden.

Jedes Item trägt eine Beschreibung, einen Rang und, für die oben stehenden, eine Grössenschätzung. Die Liste hat keine genehmigte Endfassung: Ihre Gültigkeit hängt am Datum ihrer letzten Durchsicht. Das Team zieht sie bei, um zu entscheiden, was es als Nächstes nimmt, die Stakeholder, um zu sehen, was unmittelbar ansteht, was weiter entfernt liegt und was vielleicht nie umgesetzt wird.

Die Technik betrifft die Führung und die Ordnung des Backlogs. Die Backlog-Verfeinerung, von den Teams meist Refinement genannt, ist die laufende Tätigkeit, die ein Item zerlegt und ausdetailliert, bis es so umsetzbar ist, wie es dasteht. Beides läuft oft in derselben Sitzung ab, und die beiden zu verwechseln kommt teuer zu stehen. Ein Team, das seine Durchsicht damit verbringt, die obersten drei Items zu zerlegen, ordnet den Rest nie neu, und das untere Ende des Backlogs veraltet.

Einsatz

Wann einsetzen

• Nachfrage dauerhaft über der Kapazität: mehr bekannte Items, als das Team bearbeiten kann.
• Prioritäten, die sich unterwegs verschieben: die laufende Ordnung entscheidet, was als Nächstes bearbeitet wird.
• Ständiger Zufluss: Fehler, Änderungsanträge und Wartung treffen unangekündigt ein und werden gegen alles Übrige abgewogen.
• Ungleichartige Arbeit, die zusammen abzuwägen ist: User Stories, nichtfunktionale Anforderungen, Fehler und Dokumentationsaufgaben in einer einzigen Warteschlange.
• Schubweise frei werdende Kapazität: das Team zieht das nächste Item, sobald ein Platz frei wird.

Wann nicht einsetzen

• Vertraglich fixierter und vor der Umsetzung sequenzierter Umfang: in diesem Fall sind ein Umfangsdokument und ein Projektterminplan die besseren Instrumente.
• Eine Handvoll Items ohne Zufluss: eine Aufgabenliste genügt; die regelmässige Durchsicht kostet mehr, als sie einbringt.

Beschreibung

Was ins Backlog kommt

Ein Item kommt ins Backlog, wenn es für einen Stakeholder Wert hat. Das Kriterium ist mit Absicht weit. Ebenso weit ist die Liste der Item-Typen: Anwendungsfälle, User Stories, funktionale und nichtfunktionale Anforderungen, Designelemente, Kundenaufträge, Änderungsanträge, Fehler, geplante Nacharbeit, Wartung, Risiko-Items, bis hin zu „eine Präsentation halten“ oder „ein Dokument schreiben“.

Der verbreitetste Fehlgriff ist, das Backlog als Funktionsliste zu behandeln. Ein Team, das nur User Stories darauf schreibt, wägt seine Fehler, seine technischen Schulden und seine Dokumentationspflichten in einer parallelen Warteschlange ab, die nie mit dem Produkt konkurriert. Die Wartung kommt deshalb nach allem anderen, weil sie nie mit irgendetwas in Konkurrenz gesetzt wurde. Das Item Tracking bleibt nützlich, um den Lebenszyklus eines Fehlers oder eines offenen Punkts zu tragen; das Backlog trägt die Abwägung zwischen diesem Fehler und allem, was mit ihm konkurriert.

Das Recht, ein Item hinzuzufügen, wird ausdrücklich entschieden. Drei Formen kommen vor: Eine einzelne Person besitzt die Befugnis zum Hinzufügen, ein Gremium entscheidet im Konsens oder die Verantwortung liegt bei der Business-Analystin. Dazu kommen Regeln für den automatischen Eintritt, etwa die Pflicht, jeden schweren Fehler mit seiner Qualifizierung einzutragen. Unter einer formellen und prüfbaren Änderungs-Governance speist das Backlog den Prozess, aber massgebend bleibt das Register der Änderungsanträge. Ein Team, das diese Frage nie entschieden hat, hat sie stillschweigend entschieden: Alle tragen ein und das Backlog wird zum Ort, an dem man ablegt, was man nicht vergessen will.

Das Detail verdichtet sich oben

Items nahe dem oberen Ende sind ausführlich beschrieben, mit einer Schätzung von Grösse und Komplexität, die verlässlich genug ist, um daraus Kosten und Aufwand abzuleiten. Diese Grösse wird in einer relativen Einheit ausgedrückt, in Punkten oder in T-Shirt-Grössen, je nach Team. Ein Item, das weit unterhalb der Spitze eingetragen wird, erhält das Minimum an Arbeit, das nötig ist, um zu verstehen, was es mit sich bringt. Steigt seine Priorität, wird es durchgesehen, allenfalls zerlegt und feiner geschätzt.

Diese Verdichtung macht die Technik in jeder Grösse tragfähig: dreihundert Items auf demselben Detailniveau auszuarbeiten kostet Wochen, liefert Zahlen, die vor ihrem Gebrauch veraltet sind, und speist eine Entscheidung, die nur die ersten Items betrifft. Die Kehrseite ist eine Teamdisziplin: ein Item vom unteren Ende nicht auszudetaillieren, solange sein Rang sich nicht bewegt.

Kosten und Aufwand, die abgeschlossene Items verbraucht haben, dienen dazu, die Schätzungen der verbleibenden neu zu kalibrieren: Ein Team, das regelmässig zum Doppelten seiner Schätzung liefert, lernt diese Abweichung und rechnet sie auf den Rest des Backlogs an. Die Schätzung wird so zu einem wiederkehrenden Akt, nach dem Muster der rollierenden Schätzung.

Die Priorität, in zwei Schritten

Items werden im Verhältnis zueinander priorisiert. Diese relative Priorität bewegt sich: Die Bedürfnisse der Stakeholder ändern sich, zwischen Items entstehen Abhängigkeiten und auch die Regeln des Backlog-Managements wirken auf die Ordnung.

Beim Eintritt ist die Priorisierung grob: hoch, mittel oder tief. Die Items der Gruppe hoch werden häufiger durchgesehen, denn sie sind die Kandidaten für die nächste zugesagte Arbeit. Um sie auseinanderzuhalten, greift innerhalb dieser Gruppe eine feinere Rangfolge, etwa ein numerischer Rang auf der Grundlage eines Wertmasses. Das BABOK beschreibt diesen Mechanismus, ohne eine Methode zu nennen. MoSCoW, WSJF und die Verzögerungskosten (Cost of Delay) sind mögliche Umsetzungen davon; die Verzögerungskosten, von Reinertsen formalisiert, eignen sich für einen Rang, der bei jeder Durchsicht neu bestimmt wird, weil sie eine Zahl liefern, die zwischen Items unterschiedlicher Art vergleichbar ist.

Der Übergang von der Gruppe zum Rang ist der Unterschied zwischen Gruppierung und Rangfolge. Die erste sortiert die Items in einige wenige gemeinsame Kategorien, ohne Ordnung innerhalb einer Kategorie. Die zweite gibt jedem Item eine eindeutige Position. Ein Backlog lebt mit beidem: eine Gruppierung über das Ganze, eine Rangfolge an der Spitze der Liste.

Das BABOK spricht von Priorisierung und von relativer Priorität. Der Scrum Guide beschreibt das Product Backlog als geordnete Liste und verwendet das Vokabular der Priorisierung nicht: Für diese Ordnung steht der Product Owner ein. Die beiden Vokabulare bezeichnen benachbarte Praktiken, ohne austauschbar zu sein. Das Wort des Referenzwerks zu verwenden, von dem gerade die Rede ist, vermeidet in der Sitzung Mehrdeutigkeit.

Items auswählen und wieder herausnehmen

Wird Kapazität frei, sieht das Team das obere Ende des Backlogs durch und wählt nach dieser Kapazität aus, nach den Abhängigkeiten zwischen den Items und nach dem, was es in diesem Moment von deren Grösse und Komplexität versteht. Der Rang leitet die Auswahl, ohne sie zu diktieren: Ein Item auf Rang 2, dessen Voraussetzung nicht bereitsteht, macht dem nächsten Platz.

Ein Item verlässt das Backlog aus zwei Gründen: Es ist fertig oder es wurde entschieden, nicht weiter daran zu arbeiten. Ein entferntes Item kann zurückkehren. Das BABOK nennt dafür vier Anlässe: eine wesentliche Änderung der Bedürfnisse der Stakeholder, eine Arbeit, die länger dauert als geschätzt, andere vorrangige Items, die ihre eigene Schätzung überziehen, oder ein ausgeliefertes Produkt mit Fehlern. Ein Item zu entfernen ist deshalb eine wenig kostspielige Entscheidung: Man kann bedenkenlos ausmisten und später wieder eintragen.

Was sagt die Grösse des Backlogs?

Die Zahl der Items wird über die Zeit verfolgt. Ein wachsendes Backlog signalisiert eine steigende Nachfrage oder eine sinkende Produktivität; ein sich leerendes Backlog signalisiert eine sinkende Nachfrage oder einen verbesserten Herstellungsprozess. Die Kurve allein sagt nicht, welches von beidem zutrifft. Die Ursache wird bei jedem Knick gesucht, auf der Seite des Zuflusses wie auf der Seite der gelieferten Kapazität.

Eine Organisation führt oft zwei davon: ein Gesamtbacklog, das alles Bekannte versammelt, und ein zweites, beschränkt auf das, was in einem kurzen Horizont umgesetzt wird, gespeist aus dem ersten. Die Unterscheidung nützt, wenn die beiden Zielgruppen verschieden sind, ein Portfolioausschuss beim ersten und ein Umsetzungsteam beim zweiten. Sie wird mit Abgleicharbeit bezahlt: Ein Item, das in die kurze Liste aufsteigt, muss die Warteschlange der Gesamtliste verlassen, sonst existiert es zweimal und wird zweimal geschätzt.

Drei Fallen, die ein Backlog seines Sinns berauben

Die erste ist das Backlog, das zur Ablage geworden ist: Ab einem gewissen Volumen wird es schwer zu führen. Die Durchsicht kommt nur noch über die ersten zwanzig Items. Ein Item, das vor sechs Monaten mit drei Wörtern Beschreibung eingetragen wurde, versteht niemand mehr. Der Informationsverlust geht umso schneller, als das Detail dort bauartbedingt dünn ist. Die Gegenmassnahme ist, den Austritt zu bejahen: Ein Item, das zwei aufeinanderfolgende Durchsichten nicht erklären konnten, wird entfernt, notfalls kehrt es richtig beschrieben zurück.

Die zweite ist die fehlende Regelmässigkeit. Die periodische Durchsicht des Ganzen trägt alles Übrige, denn dort übersetzen sich geänderte Bedürfnisse in geänderte Ränge. Ohne geplantes Intervall schrumpft die Durchsicht auf die Vorbereitung der nächsten Iteration und die Ordnung am unteren Ende erstarrt.

Die dritte ist die Ordnung, für die niemand einsteht. Ein Rang, der aus einer Gesprächsrunde stammt, ohne festgehaltenes Kriterium, wird in jeder Sitzung angefochten und bei jedem Wechsel des Gegenübers neu ausgehandelt. Zu benennen, wer entscheidet, und das Kriterium festzuhalten kostet einige Minuten je Durchsicht und macht die Ordnung an dem Tag verteidigbar, an dem jemand fragt, warum sein Item hinter ein anderes gerutscht ist.

KI-Überlegungen

Drei Einsätze rechtfertigen sich auf einem umfangreichen Backlog. Der erste ist die Erkennung semantischer Dubletten: zu erkennen, dass zwei unterschiedlich formulierte Items denselben Bedarf beschreiben, bevor beide geschätzt und dann umgesetzt werden. Auf mehreren Hundert Zeilen, die sich in zwei Jahren angesammelt haben, ist das eine Arbeit, die keine menschliche Durchsicht leistet. Der zweite ist die Alterungsanalyse: die Items nach oben holen, die seit N Zyklen keine Durchsicht mehr berührt hat, damit ein Mensch entscheidet, ob er sie im Detail wieder aufnimmt oder entfernt. Der dritte ist das Verfassen einer ersten ausführlichen Beschreibung und von Akzeptanzkriterien, wenn ein Item von unten nach oben wandert, aus dem heraus, was das Item bereits trägt. Eine Schätzbandbreite, abgeleitet aus dem historischen Durchsatz vergleichbarer Items, kommt bei Bedarf dazu; die Business-Analystin überarbeitet diesen Text und lässt ihn bestätigen.

Die Maschine ordnet nicht um: Der Rang drückt den Wert für Stakeholder und eine Abwägung zwischen ihnen aus, die sich aus dem Text der Items nicht ableiten lässt. Sie führt eine vermutete Dublette weder zusammen noch löscht sie diese ohne menschliche Bestätigung, denn ein Item, das redundant wirkt, kann sich aus Gründen wieder öffnen, die im Text nicht stehen. Sie liefert keine Schätzung, ohne zu zeigen, worauf diese beruht, sonst kann sie niemand in der Durchsicht verteidigen. Schliesslich ist der Inhalt der Items Projektinhalt wie jeder andere: Das Backlog eines Versichertenportals trägt Leistungsbezeichnungen, Dossiernummern und Beschreibungen von Fehlern, die Gesundheitsdaten berühren. Das Werkzeug, das diese Texte verarbeitet, untersteht denselben Anforderungen an den Datenschutz wie das System selbst.

Beispiele

Die Position eines Items bestimmt seinen Grad an Detail und Schätzung. Das folgende Backlog gehört dem Team, das das Versichertenportal eines Krankenversicherers erneuert.

Eine User Story, eine nichtfunktionale Anforderung, ein Fehler, ein Anwendungsfall, ein Änderungsantrag, ein Risiko und eine Schreibaufgabe streiten um dieselbe Warteschlange und dieselbe Spitze der Liste. Der Abrechnungsfehler geht der Barrierefreiheit des Anmeldebildschirms vor, weil er einen Betrag betrifft, der dem Versicherten angezeigt wird, eine Abwägung, die zwei getrennte Warteschlangen nie ermöglicht hätten.

Die Durchsicht vom 12. März hat den Abrechnungsfehler in die Gruppe Hoch geholt, auf Rang 3, an dem Tag, an dem der Kundendienst elf Anrufe zum selben falschen Saldo gezählt hat; sie hat die Benachrichtigung per SMS, seit dem Herbst auf Mittel gehalten, auf Tief zurückgestuft, als die E-Mail genügte. Der Antrag auf Kostenübernahme im Ausland wartet auf zwei Dinge, bevor er geschätzt wird: die Bestätigung, dass solche Behandlungen unter die Grundversicherung fallen, und die Antwort des Abrechnungspartners zum Austauschformat. Solange diese beiden Punkte offen sind, würde ein Zerlegen Arbeit kosten, die ein zweites Mal zu leisten wäre; seine Grössenordnung genügt, um ihn mit den anderen zu vergleichen.

Visualisierungen

Das Ergebnis ist die Tabelle selbst, in HTML geschrieben. Der Gebrauch des Artefakts liegt in drei Handlungen, die ein Bild verliert: nach dem Rang sortieren, auf einen Typ filtern und eine Zeile nachlesen, um eine Position zu begründen.

Der Mechanismus, der diese Tabelle erzeugt, passt nicht in sie hinein. Die Verdichtung des Details an der Spitze ist eine räumliche Eigenschaft: Sie zeigt sich, wenn die Items oben Platz beanspruchen, mit ihrer Beschreibung und ihrem Schätzabzeichen, wenn die in der Mitte auf eine Bezeichnung schrumpfen und wenn die unten nur noch Marken ohne Beschriftung sind. Zwei Pfeile vervollständigen die Lesart: einer verlässt die Spitze für die Auswahl, der andere führt für die periodische Durchsicht wieder nach oben.

Aufwand

Werkzeuge

Für ein kleines Team leistet eine gemeinsame Tabellenkalkulation oder ein Kanban-Board, physisch oder in einem leichten Werkzeug wie Trello, den Dienst ohne Kosten. Die Ordnung ist die Position der Zeile oder der Karte, der Typ ist eine Spalte oder eine Etikette und die Durchsicht besteht im Verschieben der Karten. Ab einigen Dutzend Items machen fehlender Verlauf und fehlende Filterung die Verfolgung der Grösse undurchführbar.

Auf der Ebene eines Produktteams oder einer Abteilung tragen Jira, Azure DevOps Boards und ihresgleichen von Haus aus, was die Technik verlangt: einen Rang per Ziehen, eine Typisierung der Items, die Stories, Fehler und Risiken in einer einzigen Warteschlange mischen lässt, und ein Durchsatzprotokoll, das die Neukalibrierung der Schätzungen speist. Diese Werkzeuge machen auch die Alterung messbar, über eine Abfrage auf das Datum der letzten Änderung.

Wird das Backlog von einer formellen Bedarfssteuerung gespeist, stellen die Demand- oder Portfoliomodule einer Service-Management-Plattform, ServiceNow etwa, die Verbindung zwischen dem Eingang der Anträge und der Umsetzungswarteschlange her. Das Anti-Werkzeug bleibt die Präsentation: Ein Backlog in einem Foliensatz lässt sich nicht sortieren, lässt sich nicht filtern und ist am Tag nach seiner letzten Aktualisierung falsch.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.2 Backlog Management: die Definition des Backlogs, die sechs Entscheidungen seiner Führung, die Liste der Item-Typen, die Governance des Eintragens, die Priorisierung in mehreren Phasen, die Verdichtung des Details an der Spitze, die Gründe für Austritt und Wiedereintrag, die Lesart der Grössenschwankungen und die genannten Grenzen.
• Ken Schwaber und Jeff Sutherland, The Scrum Guide (2020), Abschnitt „Product Backlog“: das Product Backlog als geordnete Liste definiert, für die der Product Owner einsteht, und die Backlog-Verfeinerung als laufende Tätigkeit bezeichnet.
• Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing: die Verzögerungskosten als ökonomisches Mass relativen Werts, brauchbar, um Items derselben Prioritätsgruppe auseinanderzuhalten.