… und was du dagegen tun kannst.

Wie im letzten Blog Post dargestellt, ist das Template der User Story scheinbar relativ simpel:

“Als User möchte ich mich einloggen, damit ich mich einloggen kann.”

“Als User möchte ich über ein Cookie automatisch einloggt werden, damit ich meine E-Mail-Adresse nicht immer eingeben muss.”

Solche Beispiele treffen wir in der Praxis häufig an. Du fragst dich nun, was an diesen User Stories verbesserungsbedürftig ist. Nun einiges. Betrachten wir das erste Beispiel:

“Als User möchte ich mit einloggen, damit ich mich einloggen kann.”

Hier ist nicht zu erkennen, was der Grund, bzw. der Nutzen dieses Einloggens ist. Welche Vorteile hat der User wenn er eingeloggt ist? Könnte er die nachfolgenden Schritte auch tun ohne sich einzuloggen? Hier fehlt das eigentliche Bedürfnis des Users. Für die Umsetzung ist nicht klar, welches Ziel der Anforderungssteller verfolgt. Um das Ziel einer User Story herauszuschälen, eignet sich beispielsweise die 5-Why Technik:

  1. Wozu möchtest du dich einloggen?
    → Damit ich meine letzte Espresso-Kaffeekapsel Bestellung sehen kann.
  2. Wozu  möchtest du diese sehen?
    → Damit ich beim nächsten Besuch des Webshops einen vergangenen Einkauf wiederholen kann.
  3. Weshalb möchtest du einen Einkauf wiederholen?
    → Damit ich Zeit spare und es bequem mag, da ich oft dieselben Kapseln bestelle.
  4. Weshalb ist dir die Zeitersparnis so wichtig?
    → Da ich spät nach Hause komme, möchte ich die Zeit nicht am PC, sondern mit der Familie verbringen.
  5. Weshalb kommst du spät nach Hause?
    → Weil meine Zugverbindungen zur Arbeitsstelle nicht optimal sind.

Dieses Frage-Antwort Spiel sollte man so lange spielen, bis man zum eigentlichen Bedürfnis vorgedrungen ist. Das kann manchmal schmerzhaft sein, denn dazu muss man sein Wünsche und Bedürfnisse äussern können. In diesem Beispiel werden wir kaum die Fahrpläne der SBB anpassen können, jedoch wird klar, dass der Zeitgewinn und Komfort für den Nutzer die eigentlichen Bedürfnisse darstellen. Nun kann die IT sich überlegen, wie dieser Zeit-/Komfortgewinn optimal realisierbar ist. Da der Lösungsraum der User Story dadurch offen bleibt, ist die Suche nach der besten Möglichkeit nicht eingeschränkt. Es werden entgegen der ursprünglichen User Story Lösungen gefunden, welche oftmals ganz anders lauten. Zum Beispiel automatische Lieferung der letzten Bestellung nach einer vom User definiert Zeit.

Betrachten wir nun das zweite Beispiel:

“Als User möchte ich über ein Cookie automatisch einloggt werden, damit ich meine E-Mail-Adresse nicht immer eingeben muss.”

Hier versteckt sich bereits eine vordefinierte Lösung, nämlich dass das Einloggen via eines Cookies passieren soll. Wozu ist dies notwendig? Würden nicht auch Iris-Scan, Facebook/Gmail Button, SmartCard/Fingerprint, MobileTAN oder Ähnliches genauso funktionieren? Wenn der Product Owner User Stories formuliert, so tut er dies gewöhnlich aufgrund seines Erfahrungsschatzes. Wenn er in der Vergangenheit bereits solche Lösungen mit Cookies umgesetzt hat, so denkt er sich, dass dies der Entwicklung helfen würde, wenn er bereits einen Lösungsansatz vorgibt. Leider ist genau das Gegenteil der Fall. Die Entwicklung wird um elegante oder effizientere Lösungen beraubt. Auch hier gilt wiederum zu klären, weshalb es genau dieser Cookie-Ansatz sein soll. Es könnte durchaus sein, dass vordefinierte Richtlinien dies so fordern, oder ein bestehendes Modul wiederverwendet werden soll, usw. Meist gibt es jedoch keinen triftigen Grund, warum bereits jetzt schon eine Lösung vorgeschrieben werden soll. Für unser Beispiel könnte eine lösungsneutrale Formulierung so lauten:

“Als registrierter Kunde möchte ich meine letzte Espresso Bestellungen komfortabel wiederholen, ohne dass ich mir ein Passwort merken muss oder meine E-Mail-Adresse eingeben muss.

Somit wird dem Umsetzungsteam der effizienteste Lösungsansatz überlassen und der Product Owner kann mit innovativen Ideen überrascht werden, was bekanntlich die Zufriedenheit überproportional steigern kann (siehe Kano Model). 

Damit bei der Formulierung von User Stories der Fokus auf das “WOZU”, bzw. das “WAS” anstelle des “WIE” gelegt werden kann, hat sich folgendes Vorgehen bewährt:

  1. Stelle das Ziel der User Story an den Anfang
  2. Reduziere die Template “Als <Rolle> möchte ich <Bedürfnis> damit <Nutzen> auf die wesentlichen Elemente und lass die Füllwörter weg.

Die obige Story würde danach so aussehen:

Ziel: Komfortabel Bestellungen wiederholen
Rolle: Registrierter Kunde
Bedürfnis: Login automatisch durchführen ohne Eingabe von E-Mail-Adresse und Passwort

Im nächsten Blogpost wird erklärt, wie Abhängigkeiten in Stories vermieden werden können: Abhängigkeiten / Stories richtig  schneiden (folgt…)