Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

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

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps
Team
User Story
Paulina Heins
November 9, 2020

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen