Wie können Anforderungen zergliedert, gemanaged und priorisiert werden? Das ist eine wichtige Frage, besonders wenn man in einem Projekt mit klassischen Ansätzen ein Vorgehen nach agilen Maßstäben etablieren will. Als Scrum Master werde ich Coach des Product Owners.

Das Arbeiten mit agilen Ansätzen unterscheidet sich doch sehr vom klassichen / wasserfallgetrieben Vorgehen mit “vollständig ausformulierten” Spezifikationen. An diesem Punkt anzusetzen, war das Wichtigste, denn eine zentrale Frage war, was der Product Owner mit seinem schon vor langem erstellten Lastenheft tun soll.

Wegwerfen, ignorieren und von vorne beginnen Anforderungen in Form von Epics und User Stories zu erstellen? Wohl eher nicht, aber das war zumindest die Befürchtung des Product Owners, nach dem ich ihm in einem schnellen Durchlauf die Grundzüge von Scrum, Impact Mapping, Story Mapping und das Konzept der User Stories vorstellte. Zum Verständis, was zu tun ist und wie das Ziel eines priorisierten Backlogs unter Nebenbedingungen erreicht werden kann, trug das Modell der 3 Ebenen des agilen Anforderungsmanagements bei.

Die 3 Ebenen des agilen Anforderungsmanagements

Das Ziel ein sauber priorisiertes Backlog, bei dem es nicht nur Prio 1 gibt, zu erstellen, lässt sich in einer Anforderungspyramide ausdrücken: während von unten die groben Anforderungsüberschriften (Epics, Themen) nachgeschoben und mit der Zeit näher erläutert werden, ist es am Scrum Team die detaillierte Spitze (User Stories, Tasks) abzutragen. Das Modell stellt gleichermaßen ein Prozess wie auch ein Vorgehen dar. Im ersten Moment kommt dabei einem vielleicht Kanban in den Sinn, aber wie es sich zeigte, änderten sich im Projektverlauf die Anforderungen des Product Owners, so dass das vormals mit viel Mühe erstellte Lastenheft in seiner Aktualität gegenüber der sich nun entwickelnden Vision allmählich verblasste. Und wie es sich zeigte wurde das nicht mit Tränen und Wehmut quittiert - der Weg für ein visionäres Vorgehen mit Scrum war nun endlich frei geworden.

Die drei Ebenen stehen in gewissem zeitlichen Zusammenhang. Aus einer Top-Down-Sicht sind die Dinge, denen man sich jetzt widmet, ausführlich und SMART genug beschrieben. Je weiter man in die Zukunft blickt, desto eher lässt man Unschärfen zu, sollte aber den INVEST+E nicht aus dem Fokus verlieren. Wird es Visionär, hilft es die Hintergründe mit einem DEEP+ER Ansatz zusammenzuhalten. Jede Ebene für sich, unterstützt das agile Anforderungsmanagement in der Weise, dass Änderungen möglich sind und nicht zu teuer werden. In dieser Betrachtung hilft DIVE den Fokus auf das Wertvolle und Nutzenstiftende zu behalten.

Die einzelnen Ebenen des agilen Anforderungsmanagements sind in der Form eines gereihten Produkt Backlogs (von oben nach unten) zu verstehen.

DIVE into

Über allen drei Ebenen schwebt das Akronym DIVE. Es verfolgt das Ziel einer linearen Ordnung der Produkt Backlog Einträge.

• D ependencies
  • Selbst wenn die Abhänigkeit aller Epics und Stories weitgehend verringert ist, können dennoch einige Abhängigkeiten übrig bleiben. Diese Abhängigkeiten sollten bei der Priorisierung im Backlog antizipiert werden. Hängt beispielsweise ein Backlogeintrag A von B ab, so sollte B vor A berücksichtigt und höher priorisiert werden.
• I nsure against Risks
  • Risiken sollten auch im Vorgehen nach agilen Maßstäben berücksichtigt werden. Dabei geht es gleichermaßen um technischen wie auch um geschäftliche Risiken.
• Business V alue
  • Wer den Geschäftswert nicht berücksichtigt, begibt sich möglicherweise auf träumerische Pfade für Produkte, die an der Nutzergruppe völlig vorbeigehen.
• Estimated E ffort
  • Der geschätzte Aufwand für die Realisierung sollte nicht unberücksichtigt bleiben. Zusammen mit dem Geschäftswert kann eine Aussage zum Return on Invest (ROI) getroffen werden, was eine beliebte Kennzahl bei Geschäftsführern ist.

DEEPER Product Backlog

In der gesamten Tiefe (vertikal) des Product Backlogs sollte D E E P + E R angewandt werden.

• D etailed appropriately
  • Gerade im unteren Bereich der Anforderungspyramide, dem Bereich der vagen noch relativ unkonkreten Backlogeinträge, spielen Details noch keine große Rolle. Je näher jedoch eine Realisierung für ein Backlogeintrag bevorsteht, desto detaillierter und exakter sollten die notwendigen Informationen sein, ohne jedoch sich in ihnen zu verlieren.
• E stimated
  • Nach Möglichkeit sollten die Product Backlog Einträge in Bezug auf ihre Komplexität geschätzt vorliegen. Ganz neue Backlogeinträge haben zumeist noch keine Schätzung und finden sich im unteren Teil des Backlogs - weit entfernt von einer nahenden Realisierung.
• E mergent
  • Insbesondere Scrum baut auf den Ansatz “Inspect and Adapt”. Feedback vom Nutzer kann dazu führen, dass Backlogeinträge an anderen vorbei nach oben geschoben werden, da sich ihr erwarteter Nutzen / Geschäftswert erhöht hat. Das Product Backlog ist niemals statisch und befindet sich fortlaufend in einer Umgestaltung.
• P rioritized
  • Das Backlog sollte zu jedem Zeitpunkt priorisiert vorliegen. Die aktuell wichtigsten und klarsten Einträge finden sich an der Spitze, die neuen und aktuell nicht so wichtigen Einträge finden sich im unteren Bereich.
• E rosive
  • Idealerweise hat das Backlog einen Bezug zu einer Vision und drückt in seiner Gesamtheit alle Aspekte dieser Vision aus. Jeder Aspekt im Backlog sollte einen Teil der Vision bis zur Realisierung (ab)tragen.
• R eturn on Invest
  • Dem Aufwand einer Realisierung sollte auch immer ein angemessener Ertrag gegenüber stehen. Es ist nicht zwingend, dass dieser Ertrag in Form eines Geldbetrages ausgedrückt wird. Ebenfalls ist denkbar ein Value anzusetzen (Value on Invest - VoI).

INVEST+E in das Sprint Backlog

Umso mehr sich Epics in User Stories untergliedern, die auf sie einzahlen, und sich damit für eine Realisierung in einem Sprint anbieten, desto stärker sollte auf INVEST+E geachtet werden.

• I ndependent
  • Damit einzelne User Stories überhaupt in einen Sprint genommen und somit die Realisierung abgegrenzt werden kann, sollten sie möglichst unabhängig von anderen User Stories sein. Ist das nicht möglich, orientiere dich an DIVE.
• N egotiable
  • Über die Realisierung einer User Story in einem Sprint sollte verhandelt werden können. Insbesondere dann, wenn es zu einer Situation
• V aluable
  • Die Umsetzung einer User Story sollte einen (Mehr-) Wert liefern - vermeide Überflüssiges und orientiere dich am Minimum Viable Product
• E stimable
  • Kann über eine User Story keine hinreichende Schätzung zu ihrer Komplexität abgegeben werden, dann ist sie möglicherweise zu komplex. Es bietet sich an, die Anforderung kleiner zu schneiden und die Komplexität dann erneut zu schätzen.
• S mall
  • Die Anforderung sollte klein genug sein, so dass sie in einer Sprintlänge realisiert werden kann und danach potentiell einsetzbar ist.
• T estable
  • Die Formulierte Ergebniserwartung sollte testbar sein. Kann das Ergebnis nicht getestet werden, sollte über ein anderes
• +
• E xample
  • Wenn möglich, kann mit einem vielleicht schon existierenden Analogon ein vergleichendes Beispiel benannt werden. Es kann zum besseren Verständis über das erwartete Ergebnis führen.

SMART Tasks

Zu guter Letzt ist es am Team zu den gewählten User Stories für einen Sprint (Selected Backlog) einzelne Tasks (Aufgaben) zu erfassen, die sich möglichst an SMART orientieren sollten.

• S pecific
  • Ein Task sollte eindeutig definiert sein; nicht vage, sondern so präzise wie möglich.
• M easureable
  • Der Task sollte im Ergebnis messbar sein; Kriterien für die Messbarkeit benennen.
• A chievable
  • Ein Task muss erreichbar / machbar sein.
• R elevant
  • Der Task sollte für die ausgegebene Zielsetzung der User Story Relevanz haben.
• T imeboxed
  • Ein Task sollte eine klare Deadline haben (kleiner als die Deadline der User Story). Zumeist werden Tasks in der Länge von einem halben bis einem Tag formuliert.

Externe Referenzen

• DIVE the product backlog carefully