Agile Minds

Der Missing Link zwischen dem großen Ganzen und den User Stories im Backlog

Agile Vorgehensmodelle begeistern viele Softwareentwickler und Projektverantwortliche, die wieder und wieder erlebt haben, wie es sich anfühlt, wenn trotz mühselig erstellter Projektpläne und Produkt-Roadmaps, Zeitpläne nicht eingehalten wurden, eine gesamte Produktentwicklung komplett ins Leere lief, weil das Produkt nie nutzbar fertiggestellt wurde, Featurewünsche, die in letzter Sekunde noch in ein Produkt gequetscht werden sollten, viele Pläne über den Haufen geworfen haben usw.
Mit Agilität wird weniger Zeit auf die Planung gelegt und Änderungen jederzeit erwartet und als etwas Positives ausdrücklich begrüßt. Früh werden potentielle Kunden und Partner mit Zwischenergebnissen des Produktes konfrontiert und werden so früh zur Reflexion und ggf. Anpassung ihrer Wünsche inspiriert. Das Produkt wird in kleinen „Happen“, genannt „User Stories“, entwickelt, die in kleinen Zeiteinheiten, genannt „Sprints“, von 2 bis 4 Wochen abgearbeitet werden. Eine Story für sich hat den Anspruch bereits einen Mehrwert für den Endkunden zu bieten. Das Ergebnis einer Story Umsetzung kann bereits dem Endkunden, wie oben erwähnt, vorgeführt werden. Das Feedback kann direkt in die nächsten User Story einfließen. Schöne heile agile Welt!
Leicht werden „agile Neulinge“ von Projektmanagern mit den Fragen gestresst, wie sich denn große Featurewünsche, die aufwendig designt und geplant werden müssen, in kleine Happen aufteilen lassen? Wie kann man bei einer solch inkrementellen Vorgehensweise das große Ganze im Auge behalten? Ich wurde bei solchen Fragen auch stets unruhig und nervös und letztlich rettete ich mich mit der Aussage, dass es vor allem um das Mindset geht, das man hat, und dass man zumindest den Versuch unternehmen muss, sich auf das agile „Spiel“ einzulassen und sich anstrengen sollte, kleine User Stories zu formulieren. Wenn dies nicht jedes Mal gelingt, dann ist das halt leider so. Sehr dünn, sehr dünn, ich weiß.
Schließlich stolperte ich über „User Story Mapping“ und schnell war mir klar, dass dies der Missing Link ist: Beim User Story Mapping wird die gesamte „Geschichte“ eines Produktes erzählt. Das große Ganze wird aus „Einzel-Geschichten“ geformt: Informationen wie „wer“ macht „was“ mit dem Produkt und „warum“ macht er das, werden in Stichworten auf Karteikarten oder Post-Its geschrieben und dadurch sofort visualisiert und greifbar. Dies passiert im Team mit allen notwendigen Personen wie Produktmanager, Produkt Owner, Partner und Kunden oder deren Stakeholder. Es wird über Abläufe im Produkt diskutiert, Begrifflichkeiten geklärt, Erwartungen an ein Feature hinterfragt und beantwortet. Ergebnisse der Diskussionen münden stets im Umhängen der Karten und werden dadurch sofort für alle Teilnehmer sichtbar und leichter verständlich; ohne langwierige Erklärungen. So entsteht die „Story Map“ wobei die Einzel-Geschichten durchaus noch nicht echte User Stories sein müssen, sondern noch größere Bausteine darstellen können. Der wichtige Punkt ist, dass über das Produkt geredet wird. Die Karten sind Erinnerungsstützen. Die gesamte Map alleine reicht nicht für das Verständnis. Die Diskussion die zur Entstehung der Map geführt hat ist essentiell. So wie User Stories keine neue Variante darstellen, Anforderungen niederzuschreiben, sondern eine Arbeitsweise, so ist auch User Story Mapping eine Arbeitsweise und eben nicht nur die Ergebnis Map.
Es wäre unsinnig, hier weiter auf Einzelheiten zum User Story Mapping einzugehen. Es ist ein riesiges Thema für sich. Meine Empfehlung ist das gleichnamige Buch von Jeff Patton. Einen Vorgeschmack gibt es gratis auf youtube.com: „User Story Mapping with Jeff Patton“

Ich hatte die Möglichkeit selbst Jeff Patton bei einem Workshop live zu erleben. Ein absolutes Highlight!

Kategorien:Agile Minds