An Stelle alles im Detail zu Beginn des Projekts zu planen, werden in agilen Projektmethoden Ziele formuliert, die im Laufe des Projekts eingelöst werden. Um diesen fachlichen Anforderungen zu erfassen, könnt Ihr diese in UserStorys formulieren.
UserStorys funktionieren anders als Lasten- und Pflichtenhefte. Sie sind der Ausgangspunkt einer intensiven Kommunikation über das gewünschte Ziel.
Wenn die BERATUNG JUDITH ANDRESEN agile Projektmethoden schult, geschieht dies in Theorie (auf wachsenden FlipCharts) und in Praxis: das Schulungsteam baut gemeinsam die Lego-Stadt Agilo.
Ein Grünanlagenfahrzeug für Agilo!
Die Stadt Agilo wird als Retortenstadt zum Verkauf an drei Zielgruppen erbaut. Die nur auf Legoplatten und mit Legosteinen erbaute Retortenstadt wird möglichst lebendig gestaltet, ist wohnlich und komfortabel. Sie wird für die drei Zielgruppen
- einkommensstarke Paare,
- Familien und
- Studenten
gebaut. Dabei werden einige Stadtteile gezielt für einzelne Zielgruppen ausgestattet, andere Stadtteile richten sich an alle Zielgruppen.
Die Stadtteile sind in Epics formuliert. Nach Errichtung der ersten Stadtteile folgt die Aktion "Mehr Grün!". Um die Attraktivität der Stadt weiter zu erhöhen, werden im Rahmen dieser Kampagne
- Grünanlagen (Park, Mini-Park) geschaffen,
- der bestehende Spielplatz begrünt und
- ein Grünanlagen-Fahrzeug gebaut,
- für welches auch eine Garage errichtet wird.
Die UserStory für das notwendige Fahrzeug lautet:
Als MitarbeiterIn der Grünanlagenverwaltung benötige ich ein Fahrzeug, um Arbeitsmittel und Pflanzen zu transportieren.
Zur Überprüfung der Story existieren zwei Akzeptanzkriterien:
- Das Fahrzeug hat eine Ladefläche für Arbeitsmittel und Pflanzen.
- Das Fahrzeug wird von einer Legofigur gefahren.
Die sieben nachfolgenden Arbeitsergebnisse zeigen sehr unterschiedliche Umsetzungsformen.
Alle Teams haben gemeinsam, dass sie in der Diskussion mit dem Product Owner erörtert haben, was eine typische Menge an zu transportierenden Pflanzen und Materialien sei.
In allen Fällen haben die Umsetzungsteams Fahrzeuge gebaut, die Gemeinsamkeiten aufweisen:
- Ladefläche für die zu transportierenden Gegenstände
- Lichter an den Fahrzeugen
- Fahrerkabine
- Mit dem Fahrzeug konnten alle Straßen in Agilo befahren werden. Die Straßen waren breit genug hierfür.
Im Detail unterscheiden sich die Fahrzeuge stark. Wäre das Fahrzeug in einem Lastenheft beschrieben worden, wäre es wahrscheinlicher viel ähnlicher ausgefallen. Gleichzeitig hätte die Anforderungsseite viel länger an den Formulierungen schreiben müssen. Denn auch übergreifende Architektur-Bedingungen und Design-Entscheidungen wie Straßenbreiten oder Lichtanlagen für Fahrzeuge hätten passend formuliert werden müssen.
Mit UserStorys fällt das Team diese Entscheidungen auch. Durch ein Gespräch zwischen Anforderungs- und Umsetzungsseite werden diese impliziten Anforderungen nach und nach geklärt.
Im Zweifel wird eine Anpassung des bisherigen System notwendig sein, um die neuen Anforderungen zu erfüllen. Gleichzeitig sind die gefundenen Umsetzungen immer stimmig im Gesamtkontext. Ein "OverEngineering" findet nicht statt.
Durch die geringe Anzahl der Akzeptanzkriterien erhält das Team viel Spielraum, eine schnelle, pragmatische und passende Lösung zu entwickeln.
Die Projektbeteiligten müssen lernen, die UserStorys passend für das Projekt aufzusetzen. Fein genug, um dem Projektziel zu dienen -- grob genug, um eben jenen Spielraum für das Team zu ermöglichen.
Mit INVEST & Kommunikation über die UserStory klappt's!
Eine Hilfestellung, ob UserStorys gut geschrieben sind, ist das Abprüfen der INVEST-Kriterien:
| i | independant | Die UserStory hat keine Abhängigkeiten zu anderen UserStorys. Sie steht für sich alleine. |
| n | negotiable | Jede UserStory ist in ihrem Umfang und ihren Anforderungen verhandelbar. |
| v | valuable | Der Wert einer UserStory entsteht durch den Nutzen für den Endnutzer. Jede UserStory hat einen Geschäftswert. |
| e | estimable | Jede UserStory ist für das Team schätzbar. |
| s | small | Die Formulierung der UserStory ist möglichst klein. |
| t | testable | Die Anforderungen, die sich aus der UserStory ergeben und in den Akzeptanzkriterien benannt sind, sind testbar. |
UserStorys, die INVEST befolgen, fallen kurz aus. Die durch diese Art der UserStory formulierte Anforderung fördert das Gespräch zwischen der Anforderungs- und der Umsetzungsseite:
card > conversation > confirmation
wird oft als der notwendige Dreiklang dazu formuliert. Aus der für das Team gültigen Definition of Done ergeben sich technische Anforderungen, ebenso aus dem bereits bestehenden System.
Mögliche Umsetzungsszenarien werden von der Umsetzungsseite entwickelt und mit der Anforderungsseite erörtert. Dabei legen die Beteiligten die entgültige Umsetzungsform fest. Auch diese Formulierung ist kurz und prägnant gehalten. Handlungsoptionen werden diskutiert. Die wesentlichen Ergebnisse werden als Akzeptanzkriterien in der UserStory ergänzt.
Im Laufe des Projekts lernen alle Beteiligten, welcher Feinheitsgrad für UserStorys notwendig ist. Entsprechend werden die Produktverantwortlichen die Storys verfeinern, anpassen oder löschen. Das Gespräch über Zielsetzung und Umsetzungsformen wird aber nicht abreißen. Gleichzeitig wird sich auch die Definition of Done verändern.
Die Formulierung von UserStorys fordert von allen, auf den Punkt zu kommen. Das Wesentliche der Anforderung ist zu formulieren. Dies gilt für die Anforderungs- genauso wie für die Umsetzungsseite. Genau dies bringt alle Beteiligten ins Gespräch. Und im Gespräch liegt die Chance für den Projekterfolg.
Alle Fotos : Judith Andresen; außer Foto Arbeitsergebnis III: mindworks GmbH
Kommentar schreiben