Auftakt: Dies ist ein Blog-Beitrag zum Modul „Agile Methoden“ des Bootcamp Product Owner der Digitale Leute School. Am Donnerstag, 26. Oktober 2023, beschäftigte sich David Pereira mit den „Elementen des Backlogs“.
User Stories sind eine sehr etablierte Methode in SCRUM, Ziele und Aufgaben eines Sprints mit ihrem Kontext zu verknüpfen. Aber wie schreibt man sie richtig? Das war eines der Themen dieser Session.
Wie User Stories aussehen sollten
Ich finde am Bootcamp gut, dass unterschiedliche und ergänzende Sichtweisen auf ähnliche Methoden und Tools deutlich gemacht werden. So entwickelt sich auch der SCRUM-Prozess irgendwie von Session zu Session immer weiter. Und die User Stories werden auch in der nachfolgenden Session erneut eine Rolle spielen.
„User Stories sollen ein gemeinsames Verständnis schaffen.“
(David Pereira)
Und David interpretiert jenseits der konkreten Übungen, die wir natürlich auch in der Session gemacht haben, noch einmal den Sinn und die Ausrichtung von User Stories:
Collaboration – Understanding – Simplicity
Es sollen durch die User Stories Bilder im Kopf der beteiligten Personen entstehen, im Journalismus spricht man auch von „Kino im Kopf“. Sie sollen eine Erinnerung triggern. Und: Sie sind ohne den konkreten Teamkontext schlicht unverständlich. Daraus ergeben sich ein paar Schlussfolgerungen:
- Es geht nicht darum, immer bessere User Stories zu schreiben, sondern sie dienen einzig und alleine dafür, eine Konversation in Gang zu bringen, ein gemeinsames Verständnis zu erzeugen.
- Es ist sogar sinnvoll, „broken User Stories“ zu schreiben, damit einfach Nachfragen kommen. „Denn nur, weil alles sehr detailliert beschrieben ist, kann es trotzdem falsch sein“, so David.
- „just enough to move on“
- Es sollte die Nutzerperspektive eingenommen werden; es sollte der Wert für den Nutzer klar sein.
- Es sollte beschrieben werden, WAS gemacht werden soll, aber nicht WIE.
- Das WARUM ist wichtig.
- Einhaltung der INVEST-Kriterien.
Beispiel:
„Als Nutzer möchte ich exakt wissen, in welchem Zustand das geliehene iPhone ausgeliefert wird, denn ich möchte nicht (unberechtigt) für Schäden in Regress genommen werden.“
Der Nutzen von Story Mapping
Dass SCRUM nicht nur aus Stories und Story Points bestehen muss, zeigt das Beispiel Story Mapping. David empfiehlt dieses Tool, um den Kontext von Stories klarer zu machen. Und in der Tat lädt es zur Gruppendiskussion ein:
- Anhand einer Customer Journey werden die einzelnen Aktionen – Nutzerrollen, NICHT Personas – in einem Prozess deutlich gemacht, also beispielsweise einem Vermietservice für iPhones – unser Gruppenprojekt in der Session – der Bereich Auswahl, Mieten und Auslieferung.
- Die User Stories (also das Was und Warum) werden diesen Aktionen zugeordnet bzw. auch gezielt für sie verfasst, also beispielsweise die oben beschriebene User Story der Aktion „Vermietung“ zugeordnet.
- Dann werden die Aufgaben (also das Wie) wiederum den User Stories zugeordnet.
- Wenn es sich anbietet, werden Verknüpfungen und Verbindungen gesucht und diskutiert.
Das Tool gefällt mir sehr gut, denn es ist einfach zu bedienen und sorgt durch seine Visualisierung für deutlich mehr Klarheit über einen Prozess. Es verhindert die zu starke Orientierung an Features in einer Softwareentwicklung.
Für das Story Mapping, rät David, sollten sich die Beteiligten treffen und ausreichend Zeit mitnehmen (er empfiehlt 4 Stunden). Sie hilft auch dabei, sich auf die Ziele zu fokussieren.
Das war auf jeden Fall wieder eine sehr inspirierende Session!
Abschließender Hinweis: Immer ist es eine sehr subjektive Zusammenfassung, die ich hier verfasse. Siehst Du Dinge anders, möchtest darüber diskutieren – melde Dich gerne bei mir!