Auftakt: Dies ist ein Blog-Beitrag zum Modul “Agile Methoden” des Bootcamp Product Owner der Digitale Leute School. Am Dienstag, 02. November 2023, beschäftigte sich Jens Echterling mit der Erstellung von User Stories und den dazugehörigen Akzeptanzkriterien.
SCRUM als agile Delivery-Methode kennt viele Elemente; in den unterschiedlichen Sessions beschäftigen wir uns sehr intensiv mit einzelnen davon. Und sicherlich für die Rolle des Product Owners zentral sind die User Stories.
INVEST-Kriterien für User Stories
Im SCRUM-Umfeld sehr bekannt sind die INVEST-Kriterien. Akronyme funktionieren einfach immer gut als Merkregel 😉 Auch hier gilt meines Erachtens: Es handelt sich hier mehr um ein Gedankenmodell, als um empirisch verifzierbare und zu 100 Prozent erfolgsbringend umsetzbare Kriterien. Aber zusammengefasst:
- I = Independant (unabhängig), das heißt, die Softwareteile sollten unabhängig von einander sein.
- N = Negotiable (verhandelbar), das heißt, es geht nicht um die perfekte Lösung, sondern um eine Richtung, die sich auch verändern kann.
- V = Valuable (wertstiftend), das heißt, es soll eine Wertsteigerung (für Nutzer) erreicht werden, bestenfalls direkt, aber manchmal geht es auch nur indirekt (“Optionswert”), wenn nur mit der Erfüllung dieser User Story eine spätere realisierbar ist.
- E = Estimable (schätzbar), das heißt, der Aufwand sollte schätzbar sein, zum Beispiel über Story Points.
- S = Small (klein), das heißt, die Story sollte so klein sein, dass sie im Sprint auch umsetzbar ist.
- T = Testable (testbar), das heißt, das ausgelieferte Stück muss entsprechend der User Story auch in seiner Funktion testbar sein.
Jens empfiehlt auch, die Kriterien nicht zu sklavisch zu betrachten, sondern als Orientierung zu sehen und als Ziel, diese zu erfüllen.
Konkreter Inhalt von User Stories
Sehr gut ist auch der Inhalt bzw. die Gliederung, die Jens bei der Erstellung von User Stories empfiehlt:
- Nutzerperspektive und Kontext im einleitenden Satz: “Ich möchte … im Zusammenhang mit … weil….” Die Story Map kann dabei helfen, den Kontext zu visualisieren. “Es ist ein einfacher Satz, aber mit sehr viel Kontext”, so Jens
- Akzeptanzkritierien: Es werden Akzeptanzkriterien definiert.
- Flows/Designs: Sie dienen der Visualisierung. Dazu können zum Beispiel Wireframes aus Figma verwendet werden. Jens empfiehlt, hierzu getestete Designs zu verwenden. Entwickler sollten nicht das Frontend-Design übernehmen.
- Definition of Done: Es wird definiert, wann eine User Story als erfüllt gilt; dies ist ein wichtiges Kriterium in SCRUM.
- Optional: Sub-Tasks
Definition EPIC: Immer wieder sprechen die Referenten auch von Epics, die man als eine Zusammenfassung von User Stories zu einem Feature verstehen könnte (etwa zum “Kunden-Login”). Sie stehen hierarchisch über den User Stories und bilden für diese den Kontext.
Akzeptanzkriterien und Definition of Done
| Akzeptanzkriterien | Definition of Done |
| Build the product right | Build the right product |
| Es werden gemeinsam qualitative Kriterien entwickelt, etwa: Tests waren erfolgreich, Code wurde kontrolliert, eine Dokumentation wurde erstellt, … | Es werden Präzisierungen in der User Story vorgenommen, etwa aus “Als Nutzer möchte ich…, um…”: Limitierung auf x Zeichen, Platzhaltertext verschwindet |
| Was wird an den Nutzer ausgeliefert? | Was passiert wann? |
Jens schlägt zwei unterschiedliche Arten von Akzeptanzkritieren vor:
- Szenario: “Wenn…, dann… und dann….”
- Checkliste: Check xx Tests erfolgreich durchlaufen
Wie bei den User Stories auch, sollten diese nicht die Lösung enthalten, sondern die Absicht (wie dann der Test konkret durchgeführt wird, entscheidet das Entwicklerteam), sie sollten verständlich sein (so dass sie auch ein Stakeholder ohne Probleme versteht, also nicht zu technisch) und sie sollten eindeutig und somit testbar sein (Es müssen xx Tests durchgeführt werden).
Beispiel:
Wenn ich die Mengenangabe ändere, dann
- muss die Summe geändert werden,
- die Summe muss sofort geändert werden,
- die Mengenanzahl muss sofort geändert werden,
- es muss sichergestellt werden, dass bei einer Erhöhung der Menge das Produkt in dieser Menge überhaupt lieferbar ist,
- …
“Geteilte Verantwortung”, sagt Jens, gibt es es bei User Story und Akzeptanzkriterien. NICHT der Product Owner alleine muss diese erstellen, sondern er übernimmt die Koordinierung. Das bedeutet aber auch: “Wer neu ist, muss sehr, sehr viel Fragen stellen.” Nur so lässt sich hinter die Fassade blicken und nur so wird deutlich, wie kompliziert sich zum Beispiel auch etwas auf den ersten Blick so einfaches wie ein Kunden-Login darstellt.
In der Session haben wir – natürlich – das alles gleich wieder praktisch ausprobiert.
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!