Backlogs werden nach Aufwand, Termin und Zuständigkeit sortiert. Die Aufgabe, die Nutzende mit dem Produkt erledigen müssen, kommt in dieser Sortierung selten vor. Der Beitrag beschreibt ein Vorgehen, das jeden Backlog-Eintrag zuerst einer Aufgabe zuordnet und erst danach nach Aufwand sortiert. Damit wird sichtbar, welche Aufgaben nach der Priorisierung unvollständig bleiben.
Ausgangslage: Das Backlog kennt Funktionen, aber keine Aufgaben
Ein Backlog in einem mehrjährigen Vorhaben sammelt Einträge aus vielen Quellen: Wünsche aus Fachbereichen, technische Schulden, Befunde aus Usability-Tests, Ideen aus dem Vertrieb. Jeder Eintrag beschreibt eine Funktion. Die Verbindung zu der Aufgabe, für die Nutzende diese Funktion brauchen, steht in den wenigsten Einträgen. Wenn das Team priorisiert, sortiert es deshalb Funktionen: nach Aufwand, nach Abhängigkeiten, nach dem Termin, an dem eine Zusage fällig ist.
Das Ergebnis ist eine Reihenfolge, die im Team nachvollziehbar ist und für Nutzende zufällig wirkt. Eine Aufgabe, die aus fünf Schritten besteht, bekommt drei Schritte im ersten Release und zwei im vierten. Dazwischen erledigen Nutzende die Aufgabe außerhalb des Produkts, in Tabellen, per Mail oder im Altsystem. In einem Portalprojekt im Fintech-Umfeld haben wir beobachtet, wie Nutzende Auswertungen in eigenen Tabellen zusammentrugen, weil das Portal die Daten anzeigte, den Abruf als Report aber nicht anbot. Der Eintrag „Report-Export" stand im Backlog. Er stand dort seit Langem an einer Stelle, an der er nach Aufwand und Abhängigkeiten hingehörte.
ISO 9241-210 setzt vor die Gestaltung das Verständnis des Nutzungskontexts: Wer arbeitet mit dem System, welche Ziele verfolgen diese Menschen, welche Aufgaben erledigen sie dafür, unter welchen Bedingungen. Nutzungsanforderungen leiten sich aus diesem Kontext ab. Eine Priorisierung wird nachvollziehbar, wenn jedes Kriterium auf eine erhobene Nutzungsanforderung zeigt. Das Vorgehen unten macht aus diesem Satz vier Arbeitsschritte.
Schritt 1: Das Aufgabenmodell aus dem Nutzungskontext aufstellen
Der erste Schritt findet nicht im Backlog statt. Aus den vorhandenen Erhebungen (Kontextinterviews, Hospitationen, Usability-Tests) entsteht eine Liste der Aufgaben, die Nutzende mit dem Produkt erledigen. Jede Aufgabe hat einen Auslöser, einen Ablauf in Schritten und ein Ergebnis, an dem Nutzende erkennen, dass sie fertig sind. „Monatsreport für das Meldewesen zusammenstellen" ist eine Aufgabe. „Dashboard" ist keine.
Wenn keine Erhebung vorliegt, ist das die erste Lücke, die dieses Vorgehen sichtbar macht. Ein Aufgabenmodell aus Annahmen des Teams ist besser als keines, muss aber als Annahme gekennzeichnet bleiben, bis eine Beobachtung es geprüft hat.
Schritt 2: Jeden Backlog-Eintrag einer Aufgabe zuordnen
Jetzt wird das Backlog durchgegangen. Jeder Eintrag bekommt ein Feld „Aufgabe" und ein Feld „Schritt in der Aufgabe". Ein Eintrag kann zu mehreren Aufgaben gehören; dann steht er in mehreren Zeilen. Ein Eintrag, der zu keiner Aufgabe gehört, bekommt die Kennzeichnung „ohne Aufgabe". Diese Kennzeichnung ist eine Information und kein Urteil: Technische Schulden und Plattformarbeit gehören dazu und werden später eigenständig priorisiert.
In der Praxis ist dieser Schritt der aufwendigste. Er zwingt das Team, jeden Wunsch aus einem Fachbereich auf die Frage zurückzuführen, in welcher Aufgabe der Wunsch auftritt. Viele Einträge lassen sich dabei zusammenlegen, weil sie Schritte derselben Aufgabe beschreiben. Andere zerfallen, weil sie zwei Aufgaben vermischen.
Schritt 3: Aufgaben auf Vollständigkeit prüfen
Nach der Zuordnung lässt sich das Backlog aus der Sicht der Aufgabe lesen. Für jede Aufgabe steht fest, welche Schritte im Produkt bereits unterstützt sind, welche im Backlog liegen und welche in keinem Eintrag vorkommen. Die letzte Gruppe ist die interessanteste: Schritte, die Nutzende erledigen müssen, die aber nirgends geplant sind, weil niemand sie als Funktion formuliert hat.
Jede Aufgabe bekommt jetzt einen Status: vollständig unterstützt, teilweise unterstützt, nicht unterstützt. Dieser Status ist die Grundlage der Priorisierung, weil er die Wirkung eines Releases aus der Sicht der Nutzenden beschreibt.
Schritt 4: Erst jetzt nach Aufwand sortieren
Die Sortierung nach Aufwand, Abhängigkeiten und Terminen bleibt nötig. Sie findet jetzt innerhalb einer Aufgabe und zwischen Aufgaben statt, nicht mehr zwischen einzelnen Funktionen. Die Leitfrage lautet: Welche Aufgabe wird mit dem nächsten Release vollständig? Wenn der Aufwand für eine vollständige Aufgabe zu hoch ist, entscheidet das Team bewusst, eine Aufgabe unvollständig zu lassen, und dokumentiert, welche Schritte Nutzende bis zum Folgerelease außerhalb des Produkts erledigen. Diese Entscheidung ist legitim. Sie ist aber eine andere Entscheidung als das zufällige Ergebnis einer Sortierung nach Aufwand.
Grenzen
Das Vorgehen setzt ein Aufgabenmodell voraus, das aus Beobachtung stammt. Ohne Erhebung produziert es eine Priorisierung auf Annahmen, die genauso wenig prüfbar ist wie die bisherige. Es ersetzt außerdem keine Bewertung nach Geschäftsziel: Welche Aufgabe für die Organisation den höchsten Wert hat, entscheidet das Produktmanagement mit dem Fachbereich. Das Vorgehen sorgt dafür, dass diese Entscheidung über Aufgaben getroffen wird und die Folgen für Nutzende sichtbar sind.
Für Backlogs mit vielen hundert Einträgen lohnt sich die Zuordnung zuerst für die Kandidaten der nächsten zwei Releases. Der Rest folgt, wenn er zur Entscheidung ansteht.
Was danach vorliegt
Am Ende liegen vier Artefakte vor: ein Aufgabenmodell mit Quelle je Aufgabe, ein Backlog mit den Feldern „Aufgabe" und „Schritt", eine Übersicht des Unterstützungsgrads je Aufgabe und eine Release-Planung, die je Release benennt, welche Aufgaben vollständig werden. Mit diesen Artefakten lässt sich jede Priorisierungsentscheidung auf eine Nutzungsanforderung und deren Quelle zurückführen. Das ist die Grundlage, auf der ein Team im nächsten Refinement und im nächsten Konfliktgespräch mit dem Fachbereich arbeiten kann.