12. Oktober 2015

Die 3 Bausteine einer guten User Story. Teil 2: WAS will der User?

Share

Wer will was wozu: Auch wenn das Rezept für eine gute User Story einfach klingt, ist die Umsetzung schon schwerer und kostet immer wieder aufs neue Zeit und Gedanken. Zwar beschleunigt die Erfahrung eines Product Owners die ganze Sache wieder, aber es bleibt: Arbeit. Und so lässt meist mit der Zeit die Motivation oder auch nur die Aufmerksamkeit nach, die Stories werden kürzer, weniger durchdacht und damit schlechter.
Über die Relevanz, das „Wer“ einer User Story konkret und aussagekräftig zu benennen, ging der erste Teil dieser kleinen Blog-Reihe. Der mittlere und zentrale Teil einer User Story, das „Was“ erscheint dagegen noch am einfachsten, denn es ist die Idee, die Lösung, die der PO oder sonstige Konzepter und Entscheider erdacht haben. Und wenn das „Wer“ und das „Wozu“ in den Stories mit der Zeit immer kürzer und banaler werden, macht sich das „Was“ breit und breiter und wird dabei: präziser.
Screens und technische Vorgaben statt Problemlösungen
Aber ist das so schlimm? Eine präzise Beschreibung der erwarteten Lösung ist doch gut, sollte man doch denken!
Ja und nein. Denn es nimmt das Team aus der Verantwortung und verhindert, dass alle Beteiligten mitdenken und bessere Lösungen vorschlagen dürfen.
User Stories sind der Auftrag, den der PO an das Team erteilt. Und in einer idealen Welt aus dem agilen Lehrbuch reicht dieser eine Satz aus, damit ein autonomes Team selbstständig eine Lösung entwickelt und umsetzt.
In der Praxis finden meist Konzeption und Design außerhalb des Teams und schon weit vor der Umsetzung statt. Anschließend geht bisweilen noch ein technischer PO das Konzept durch, und erst dann wird alles zusammen dem Team präsentiert: In einer so genannten User Story, die vor allem aus dem „Was“ besteht und mit einem langen Anhang an optischen und technischen Vorgaben daher kommt.
Anders formuliert: Die Lösung steht schon längt fest, wenn die Story ans Team geht. Das Team wird zum Dienstleister, der nicht mehr mitdenken oder gar das Produkt eigenständig weiter entwickeln soll. Das Team wird zum stupiden Code-Produzenten.

Starre Lösungsvorgaben degradieren das Team zum tumben Code-Dienstleister. #UserStory

Damit gehen viele der agilen Vorteile verloren: Einerseits die besondere Qualität von Lösungen, die in crossfunktionalen Teams konzipiert und umgesetzt werden. Zweitens die Vermeidung von Waste, von geleisteter Arbeit – zu der auch Konzepte gehören – die noch nicht oder vielleicht niemals genutzt wird. Und drittens die Flexibilität, die durch eigenständige und überschaubare Aufgaben entsteht. Denn je präziser die vorgedachte Lösung wird, umso mehr hängt sie von Vorbedingungen und Implikationen ab.
Was also tun?
Zum einen: Wenn irgendwie möglich, Konzept und Design so weit wie möglich in das Team integrieren. Natürlich hilft es einem Team bei der Schätzung und Planung in etwa zu wissen, wie ein Feature oder eine Erweiterung aussehen soll. Doch Mockups oder Scribbles reichen als Orientierung aus, lassen aber genug Raum für gedankliche Weiterentwicklung und Ausgestaltung.
Zum anderen: Auch hier vom Problem her denken und nicht von der Lösung. Das heißt: Was genau braucht der in der Story genannte Nutzer, damit sein Problem gelöst ist? Das und nur das gehört in die User Story.
Wenn zum Beispiel der User eine Möglichkeit braucht, von jeder beliebigen Seite aus zur Kasse gehen zu können, dann sollte genau das in der Story stehen. Und nicht die Lösung: „Ein blauer Button mit runden Ecken als Overlay in der rechten unteren Ecke, der bei Mouseover vergrößert und ... „ – zu viel. Wenn das Team versteht, was das Problem hinter der User Story ist, wird es die bestmögliche (d.h. einfachste und gleichzeitig nachhaltigste) Lösung auf Basis des bestehenden Produktes wählen.
So viel Verantwortung darf man seinem Team schon geben. Sie werden dankbar sein.

Der 3. Baustein: Das WOZU in der User Story.