IAPM International Association of Project Managers

ende
Sie sind hier:  News & Events » PM-Artikel

Agile Projekte mit User Stories strukturieren

Für die Strukturierung agiler Projekte stehen Ihnen viele verschiedene Tools und Methoden zur Auswahl. Auf Entwickler.de hat sich Michael Bykovski Gedanken darüber gemacht und einige Denkanstöße gegeben. Er stellt sich die Frage, wie ein agiles Projekt noch vor dem ersten Sprint organisiert und abgeschätzt werden kann.
Im Folgenden fassen wir seinen Artikel für Sie zusammen.
User Stories helfen Kunden und Teammitgliedern, das Projekt zu strukturieren und eine gemeinsame Sprache zu finden.
User Stories helfen Kunden und Teammitgliedern, das Projekt zu strukturieren und eine gemeinsame Sprache zu finden.

Vom Wollen zum Machen

Hinter jedem Projekt steckt jemand, der sich vom Projekt etwas erhofft bzw. etwas erreichen möchte. Er beauftragt jemand anderen damit, dieses Wollen in die Tat umzusetzen. Als allererstes muss also derjenige, der es umsetzen soll, so genau wie möglich erfahren, was eigentlich gewollt wird. Dabei kann ihm nur derjenige helfen, der will. So umschreibt Michael Bykovski die Problemstellung der Definition eines Projektes und des Projektziels. Einfache und klare Worte. Aber wie geht das? Wie schaffen Sie es, jemandem Ihre Anforderungen und Vorstellungen so zu vermitteln, dass er diese direkt mit den passenden Maßnahmen umsetzen kann? Oder wie schaffen Sie es, genau zu verstehen, was jemand will?

User Stories

User Stories können das Mittel zur Strukturierung und Umsetzung sein. Wie gut verständlich eine User Story geschrieben ist, hängt natürlich davon ab, wer sie geschrieben hat. Stammt sie von jemandem, der sich voll und ganz mit den Usern identifizieren kann oder im besten Fall selbst ein User ist, kann die User Story durchaus sehr brauchbar sein. Wenn Ihr Kunde nicht selbst die Story verfassen will, treffen Sie sich mit ihm und sammeln Sie so viele Informationen von ihm wie möglich. Unterteilen Sie Ihre User Story in kleinere Stories, um jede einzelne Anforderung gesondert behandeln zu können.

Ein beliebtes Beispiel: Der Kunde möchte, dass seine Nutzer sich auf seiner Oberfläche mit Twitter, Google oder Facebook einloggen können. Das sind, übersetzt in die Sprache des Web-Entwicklers, der die Anforderungen umsetzen soll, drei unterschiedliche, voneinander unabhängig zu sehende Anforderungen. Der Nutzer möchte sich mit Facebook anmelden. Der Nutzer möchte sich mit Twitter anmelden. Der Nutzer möchte sich mit Google anmelden. Im Idealfall leiten Sie aus Ihrer User Story ab, wer die Zielgruppe ist, wie viel Aufwand betrieben werden muss und ob das Projekt wirtschaftlich ist. Die Auswertung der User Stories ist wichtig, damit der Prozess flüssig und effizient bleibt. Viele arbeiten gerne mit Confluence oder Jira. User Stories können bei der Definition von Aufgaben für das Projektteam von ungeheurer Bedeutung sein. User Stories können ein Lastenheft ersetzen und sind dabei im Idealfall noch viel einfacher zu verstehen als unendlich lange, technische Listen. Zudem kann der Kunde die User Story ebenso leicht verstehen und daran mitarbeiten, weil sie in seiner, in einer gemeinsamen nicht-technischen Sprache geschrieben ist. Kein Fachchinesisch. Zu beachten: Die User Stories müssen alle in einer einheitlichen Sprache verfasst sein. Sie müssen vollständig sein. Natürlich können dem Kunden auch während des Projekts weitere User Stories einfallen. Das ist in agilen Projekten kein Problem und sogar eher die Regel als die Ausnahme.

Kundenprioritäten

Stellen Sie sich nun vor, es gibt bereits eine Liste von User Stories. Das Beispiel, das Michael Bykovski nennt, beschreibt eine To-Do-Liste. Der Kunde möchte, dass Nutzer Tasks hineinschreiben können, dass diese Tasks mit anderen Nutzern geteilt werden können, dass die Tasks auch gemeinsam von Usern bearbeitet werden können, dass der Admin immer sieht, wie viele Tasks pro Tag eingetragen werden, dass der Nutzer  seine ihm zugeordneten Tasks in einer Datenbank sieht, aber sonst niemand, und dass der Nutzer Tasks zu seiner Liste hinzufügen kann. Zunächst werden Prioritäten verteilt. Es sind hier nur sechs Anforderungen. Bei vielen Projekten stehen aber oft 100 oder 200 User Stories an. Sie können sich also vorstellen, dass das Priorisieren nicht immer ganz so einfach ist. Hier rät Michael Bykovski dazu, die Aufgaben zu clustern.

Milestone Prio

Sie verwalten Ihr Projekt agil, weil Sie die Umsetzung so flexibel wie möglich halten wollen. Trotzdem haben auch Sie Deadlines und Milestones. Die agilen Methoden haben hier einen leichten Schwachpunkt, denn sie sind eher von Sprint zu Sprint gedacht, statt in eine ferne Zukunft gerichtet zu sein. Das Prinzip der Milestone Prio soll es ermöglichen, dem Kunden konkrete, fassbare Daten zu nennen. Bis zum ersten Mai werden die User Stories 1-17 abgearbeitet sein. Bei den Meetings der Milestone Prio sollte daher aus jedem Bereich ein Vertreter dabei sein, aus dem Design, dem Backend, dem Frontend, aus der Konzeption und ein Product Owner. Jeder muss die User Stories kennen. Das ist Voraussetzung für eine erfolgreiche Milestone Prio.
 
Gehen Sie in dem Meeting so vor, dass Sie die Liste der User Stories zunächst mit den Prioritäten des Kunden versehen. Dann bilden Sie auf einzelnen Blättern oder Haftnotizen die zeitliche Schiene des Projekts ab, je nach Dauer in Wochen oder Monaten. Zuerst suchen Sie die User Stories aus, die unabhängig von allen anderen User Stories bearbeitet werden können. Außerdem wird zugeordnet, welche Abteilung sich um die jeweilige User Story kümmern muss beziehungsweise wird. Dann widmen Sie sich den Stories, zwischen denen Abhängigkeiten bestehen und setzen diese in Beziehungen zueinander. Als nächsten Schritt betrachten sie die Stories, die vom Kunden mit höchster Priorität bedacht wurden.
 
Nun steht die Reihenfolge fest: zuerst werden die Aufgaben fertig, die unabhängig sind und höchste Priorität haben. Danach oder parallel werden die Aufgaben in Angriff genommen, die hohe Priorität genießen, aber Abhängigkeiten haben. Zu diesen gesellen sich die Aufgaben, die keine hohe Priorität haben, aber mit den prioritären Aufgaben in Verbindung stehen. Wichtig: nie den gesunden Menschenverstand außen vorlassen. Wenn eine Kundenpriorisierung nicht sinnvoll erscheint, kann diese geändert werden. Wenn eine kreative Idee zur Verbesserung aufkommt: Ergreifen Sie die Möglichkeit. Der Product Owner muss allerdings alle Anpassungen – vor allem bezüglich der Prioritäten – dokumentieren.

Planning Poker

Oft ist es bei agilen Projekten schwer, dem Kunden ein genaues Budget zu geben. Schließlich kann sich alles sehr schnell ändern. Sie können aber beispielsweise 80 Ihrer 100 User Stories auswählen und dafür einen Preis nennen. So kann der Kunde sich eine Vorstellung davon machen, was ihn das gesamte Projekt kosten wird oder ob er nicht vielleicht auf einige User Stories verzichten muss, um ein günstigeres Projekt zu erhalten. Dennoch müssen Sie auch bei dieser Vorgehensweise immer schätzen, was es kosten wird, eine oder eben 80 dieser User Stories umzusetzen. Hier kommt Planning Poker ins Spiel. Geben Sie Ihren Teammitgliedern Karten mit Zahlen und lassen Sie alle verdeckt eine Karte auf den Tisch legen, deren Wert dem entspricht, was sie schätzen, an Tagen oder Stunden (je nach Projekt) an Aufwand für eine Aufgabe zu brauchen. Der Mittelwert dieser Schätzungen ist oft eine gute Hausnummer. Gehen die Zahlen stark auseinander, muss vielleicht nachdiskutiert werden, worin die jeweilige Aufgabe hinter der jeweiligen User Story eigentlich besteht.
Autor: IAPM intern

Schlagworte: Wissen, Tipp, Agiles Projektmanagement, Projektstrukturierung
IAPM Partners