Für mehr Story in der User-Story

👩‍💻 Maximilian Röttgen, — 4 Minuten Lesezeit

Als ich das erste Mal eine User-Story schreiben sollte, war ich äußerst entsetzt:

Ich als Nutzer wünsche ich mir einen Warenkorb, um mir einen Überblick über meine Bestellung verschaffen zu können.

Was soll das den bitte für eine Geschichte sein? Und warum klingt jede Geschichte gleich?

Ich als <JEMAND> möchte <IRGENDWAS> tun, um ein <ZIEL> zu erreichen.

Und warum muss ich überhaupt noch „literarisch“ tätig werden, wenn ich danach eh eine Liste mit Akzeptanzkriterien schreiben muss?

[AK01] Der Warenkorb ist während des Einkaufsprozesses immer mit einem Klick erreichbar
[AK02] Im Warenkorb werden alle Items mit Titel, Bild und Beschreibung gelistet
[AK03] Es ist möglich, Artikel wieder zu entfernen und die Quantität zu ändern
[AK04] Der Nutzer kann wählen, ob er den Einkauf fortsetzen oder den Bezahlvorgang einleiten möchte

Da fragt man sich doch zurecht, weshalb es noch die vorangestellte schlechte Entschuldigung einer „Story“ (also Geschichte) braucht.

Verpasste Chance permalink

Meiner Meinung nach gibt es einen Platz und auch einen guten Grund dafür, echte Stories für Backlog-Items zu schreiben: User Experience

Gleiches Beispiel wie oben: Offensichtlich soll ein Einkaufswagen für eine Shopping-Webseite gebaut werden. Die Akzeptanzkriterien können wir also behalten. Technisch ist es ja genau das gleiche „Ding“, was am Ende herauskommen soll.

Aber wie wäre es mit folgender einleitenden Story:

Petra hat innerhalb der letzten halben Stunde mehrere interessante Produkte in unserem Shop gefunden. Wie sie es von anderen Online-Shops gewohnt ist, würde sie diese gerne irgendwie sammeln, nochmal anschauen und am Ende (hoffentlich) bestellen können.
Wir wollen ihr zu diesem Zweck – kreativ wie wir sind – einen digitalen Warenkorb zur Verfügung stellen.

Klar, die Story ist länger, weniger prägnant und gespickt mit „überflüssiger“ Information. Aber sie kommt der Realität wesentlich näher als der Text einer normalen User-Story. Die neue Story hat eine Vorgeschichte, einen Hauptteil und ein offenes Ende. Die Geschichte hat sogar eine Protagonistin.

Personas + User-Stories = Profit? permalink

Und diese Protagonistin muss der Product Owner sich im Idealfall nicht einmal selbst ausdenken. Wenn User Experience sowieso schon Thema ist, dann liegen vermutlich auch irgendwo Personas für die potenzielle Nutzergrupe herum. Warum also nicht gleich die Charaktere aus den mühsam erstellten Personas als Protagonisten in die User-Stories einbauen?

So eine Integration von Personas und User-Stories hilft womöglich zusätzlich dabei, die verschiedenen Nutzertypen im Team bekannt zu machen. Ein Team, das eine gemeinsame Idee vom technikscheuen Timo (29) oder der ungeduldigen Ulla (19) hat, kann effizienter Software für solche Personengruppen entwickeln.

Kollaboration anregen permalink

User-Stories bzw. Backlog-Items sollten keine 100% präzisen, starren, bindenden Verträge oder Anforderungskataloge sein. Sie sind vielmehr lebendige Arbeitsdokumente, die im Idealfall mit dem Produkt/Projekt reifen. Oder wie das Agile Manifest sagen würde:

Individuals and interactions over processes and tools

Standard-User-Stories bieten (meiner Meinung nach) dem Team zu wenig Anlass, sich einzubringen und dem Product Owner zu viel Versuchung, über-perfekte Backlog-Items zu schreiben und damit beim Team jegliche Motivation zum eigenständigen Denken im Keim zu ersticken.

Mit einer echten Geschichte hingegen kann sich jedes Teammitglied identifizieren – unabhängig vom technischen (oder nicht so technischen) Hintergrund und von der Position. Über eine Geschichte kann man sich austauschen, denn sie ist persönlich, weckt Emotionen und befeuert die Kreativität.

Aber ist das auch INVEST-konform? permalink

Der Scrum-Kenner kennt INVEST als Kriterienkatalog für User-Stories/Backlog-Items:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

Independent bleibt unberührt, wir ändern ja nur die Form.
Negotiable wird meines Erachtens sogar verbessert, denn es gibt jetzt tatsächlich etwas, worüber man sich unterhalten kann.
Valuable ist ähnlich wie Independent nicht weiter von der schöneren Geschichte betroffen.
Estimatable ist mindestens so gut wie vorher, wenn nicht sogar besser – immerhin kann man durch das bessere Bild, was man vom Nutzer gewonnen hat, möglicherweise besser Einschätzen, ob/welche nicht-funktionalen Anforderungen zu erfüllen sind.
Small bezieht sich auf den Umfang der Anforderung und die Dauer der Implementierung. Die User-Story an sich wird natürlich etwas länger.
Testable ist ebenfalls genauso erfüllt wie bei einer Standard-User-Story, denn die Akzeptanzkriterien sind gleich geblieben.

Fazit permalink

Es gibt eigentlich nur zu gewinnen, wenn man seinen Stories ein wenig mehr Freiraum zugesteht. Ich werde das auf jeden Fall ausprobieren, sobald ich mich noch einmal als Product Owner versuchen darf. Der Erfahrungsbericht folgt 😉