Als Berater und Beraterinnen kommen wir oft in Unternehmen, wenn die klassischen Projektstrukturen nicht mehr gut funktionieren. Denn das Umfeld, in dem unsere Kunden arbeiten, verändert sich so schnell, dass detaillierte Projektplanungen oft umsonst sind. Hier helfen agile Methoden: in kleinen iterativen Zyklen planen, ausarbeiten, das Ergebnis prüfen und die Vorgehensweise immer wieder anpassen, wo nötig.
Oft fällt es Menschen aber schwer, von den gewohnten, engen Projektstrukturen, die sie kennen, abzuweichen und anzufangen, in breiter formulierten Epics und User Stories zu denken. Das ist verständlich – detaillierte Pläne geben uns ein Gefühl von Sicherheit und Kontrolle.
Es gibt aber einen Trick, um diesem Sicherheitsbedürfnis nachzukommen. Wie bei der klassischen Projektplanung verschaffen wir uns zunächst einen Überblick über das Projektvorhaben. Dann zerlegen wir es in einzelne Teile (Initiativen oder Themen, Epics, User Stories und Tasks) und bauen so das initiale Produktbacklog auf. So haben wir eine Übersicht aller Themen, können aber immer noch flexibel reagieren, wenn sich am Markt etwas ändert.
Das Produktbacklog befüllen
Es gibt zwei verschiedene Herangehensweisen, das Produktbacklog zu befüllen, die wir unseren Kunden und Teams gerne an die Hand geben. Grundsätzlich gilt: Es gibt keinen richtigen oder falschen Weg. Als Agile Coach oder ScrumMaster finde ich die Herangehensweise, die am besten zu meinem Team oder Projekt passt.
1. Backlog-Management nach dem Eisberg-Modell
Beim Eisberg-Modell wird das Projekt in Themenschwerpunkte (Themes) aufgeteilt, die verschiedene Unterpunkte oder Funktionalitätsblöcke haben (Epics). Diese lassen sich wiederum in User Stories und Tasks aufteilen. Bei einem Projekt, das die Verbesserung der Postzustellung zum Ziel hat, wäre ein möglicher Themenschwerpunkt das Tracking von Paketen, und die Epics z. B. die Entwicklung einer Tracking-App oder die Integration mit einem Karten-Service (z. B. Google oder Apple Maps).
Stehen Themes und Epics fest, müssen pro Epic nicht sofort alle User Stories ausformuliert werden, sondern nur die, die demnächst umgesetzt werden (also die Spitze des Eisbergs). Ergo: je näher der Zeitpunkt der Umsetzung eines Epics, desto mehr User Stories und desto genauer die Planung. Ziel ist es, nur so viel Planungsarbeit wie gerade nötig zu investieren. Denn es kann z. B. passieren, dass man nach einem Monat feststellt, dass ein Epic doch nicht gebraucht wird. Dann ist es gut, wenn nicht zu viel Arbeit in die (Fein-)Planung und das Schreiben von User Stories gesteckt wurde.
2. Story Mapping / Customer Journey
Eine Story Map oder Customer Journey beschreibt die Schritte, die ein Nutzer geht, wenn er das Produkt verwendet, sowie die verschiedenen Funktionalitätsblöcke darin (Epics). So behält man einen Überblick über die wichtigsten Funktionalitäten, ohne sich dabei in Details zu verlieren. Auch hier werden zu jedem Epic User Stories geschrieben und nach Wichtigkeit priorisiert. Bei der Erstellung der Story Map hilft es, wenn nicht nur das Team, sondern weitere Expertinnen und Experten mit hinzugezogen werden, sodass ein möglichst umfassendes Bild entsteht.
Mit dem Backlog planen
Wenn ich das Produktbacklog aufgebaut habe, kann ich die Sprints planen. Unabhängig davon, ob ich das Eisberg-Modell oder Story Mapping bevorzuge – bei der Sprintplanung sollte ich beachten, dass nicht unbedingt ein Epic nach dem anderen vollständig abgearbeitet wird, sondern zunächst die wichtigsten User Stories pro Epic, damit der Nutzer möglichst schnell das Produkt als Minimum Viable Product (MVP) in den Händen hält.
Prozesse visualisieren
Das Backlog bzw. die Storymap zu visualisieren, unterstützt die Teams dabei, Prozesse besser zu durchdringen und Zusammenhänge schneller zu erkennen. „Mache Arbeit sichtbar“ ist nicht nur ein Kernprinzip der Agilität. Das Team, Product Owner und ScrumMaster erhalten so auch einen besseren Überblick über den Berg an Arbeit, den das Team zu bewältigen hat, und können kritisch hinterfragen, ob dies mit der ausgewählten Mannschaft und der vorgegeben Zeit überhaupt leistbar ist.
Machen Sie den ersten Schritt
Wenn Sie sich entschieden haben, in Ihrem Unternehmen agil zu arbeiten und ein wenig „Starthilfe“ benötigen, empfehle ich Ihnen unser Training „Agile Toolbox“ (auf Wunsch gerne remote). Wenn Sie die oben beschriebenen Methoden anwenden und dabei gekonnt visualisieren wollen, lege ich Ihnen das Training „Agile Sketching“ sehr ans Herz. Die nächsten Termine für alle unseren öffentlichen Trainings finden Sie übrigens hier.
Bild: Pexels License, Christina Morillo
