User Stories – ein fiktives Kundengespräch

Ihr habt euch entschieden, euren neuen Webauftritt von LIMESODA umsetzen zu lassen.

Nun bekommt ihr von der Projektleitung (also mir oder einer meiner Kolleg:innen ;-)) eine E-Mail, in der ich euch bitte, User Stories zu schreiben. User Stories? Fragen über Fragen. Hier die Antworten darauf:

Trocken, aber wichtig für’s Verständnis – die Begriffsdefinition:
User Stories (auf gut Deutsch „Anwendererzählungen“) sind in einem Satz formulierte Anforderungen an euren Webauftritt aus der Sicht einer bestimmten Benutzergruppe.
Die Sätze sind in Alltagssprache gehalten und haben dabei einen Aufbau von „Als [Benutzergruppe] möchte ich [Tätigkeit] um [Nutzen].“.

Eine beispielhafte User Story für unseren Blog wäre also: „Als Seitenbetreiber möchte ich unter jedem Blogpost Like- und Share-Funktionalitäten anbieten, um die Verbreitung der bereitgestellten Inhalte zu fördern“.

Damit ihr von uns am Ende auch wirklich genau das bekommt, was ihr haben wollt.
Ihr erstellt eure User Stories noch bevor wir mit unserer Hauptarbeit beginnen. Uns begleiten diese dann durch das gesamte Projekt.

Bei der Konzeption wissen wir dadurch einerseits, was wir überhaupt alles konzeptionieren müssen, andererseits erhalten wir wertvolle Hinweise zum Aufbau der Navigation sowie wesentlicher Elemente wie Startseite, Header, Footer, Contentbereich, etc.
In der grafischen Gestaltung werden Inhalte besonderer Priorität aufwändiger visualisiert bzw. an besonders augenfälligen Stellen (vielleicht auch auf jeder Seite) positioniert.
Während der technischen Umsetzung bzw. insbesondere im Testing dienen die Anwendererzählungen zur Fortschritts- bzw. Erfolgsmessung. Sind letztendlich alle User Stories auch aus technischer Sicht erfüllt, gilt das Projekt von unserer Seite her als erfolgreich abgeschlossen. Da die Stories von euch formuliert wurden, solltet ihr das dann genauso sehen.

Nein. Das würde ungefähr so viel Sinn machen, wie wenn ein Baumeister euer Haus planen würde, ohne vorher nach euren Wünschen und Bedürfnissen zu fragen – wahrscheinlich wärt ihr mit dem Ergebnis nicht sonderlich zufrieden.
Ihr habt bestimmte Vorstellungen, wie euer Webauftritt aussehen soll, was und wen ihr damit erreichen wollt und was euch dabei besonders wichtig ist. Ihr wisst Details von eurem Geschäftsfeld, die uns vielleicht zu dem Zeitpunkt noch gar nicht bekannt bzw. deren Wichtigkeit wir uns nicht bewusst sind.
Also erzählt es uns doch einfach – eben über diese User Stories.

Man nehme wahlweise ein Blatt Papier / Karteikarten und Schreibwerkzeug oder eine dreispaltige Excel-Tabelle (Spalte 1: Benutzergruppe, Spalte 2: Tätigkeit, Spalte 3: Nutzen). Entscheidend ist ein wenig Zeit und der Wille, sich um den eigenen Webauftritt Gedanken zu machen – schon ist man gerüstet für die Erstellung von User Stories.

Wenn die Ideen jetzt schon sprudeln, einfach mal drauflos schreiben. Man bekommt dann zwar keine vollständige Liste, aber die wichtigsten Anwendungsfälle sind schon mal zu Papier gebracht.

Eine strukturiertere Herangehensweise ist, sich zu Beginn mal über die Benutzergruppen Gedanken zu machen. Wer hat aller mit eurem Webauftritt zu tun? Nicht außer Acht zu lassen sind dabei auch die Nutzer, die für die Befüllung und redaktionelle Wartung zuständig sind.

Im zweiten Schritt nimmt man sich dann Gruppe für Gruppe vor und definiert aus deren Sicht, was diese genau auf der Webseite tun können sollen und wozu. Neben den funktionalen Anforderungen, die festlegen, was die Webseite leisten soll, macht auch die Definition nicht funktionaler Anforderungen Sinn. Zweitere liefern Aussagen zu Performance, Skalierbarkeit, Wartbarkeit, Sicherheit, Benutzbarkeit u. Ä.

Die Verpflichtung, einen Nutzen zu definieren, hilft, die Spreu vom Weizen zu trennen und vermeintlich nützliche, bei näherer Betrachtung aber wenig sinnvolle Features zu erkennen und wegzulassen.

Hat man die Liste der Anforderungen vollständig vor sich, fehlt nur noch deren Priorisierung.
Hier sind mehrere Varianten erlaubt, sei es durch Reihung, die Vergabe von Prioritätsstufen (z.B. 1-5), oder die Klassifizierung in Must / Should / Could / Won’t.

Nur eine messbare User Story ist eine gute User Story. Sie soll unter allen Projektbeteiligten Klarheit darüber schaffen, was gewünscht wird und dient letztendlich als Abnahmekriterium für das Projekt. Dehnbare Begriffe wie „möglichst“, „sehr“, „außergewöhnlich“, „unkompliziert“, „Wow-Effekt“, „schnell“, „einfach“, etc. liegen im Auge des Betrachters und haben darin daher nichts verloren.

Das kann man pauschal nicht beantworten. Pro Anforderung wird ein Satz ausformuliert, die Anzahl variiert je nach Komplexität und Größe des Projekts. Für die Webseite des lokalen XY-Vereins mag eine Handvoll reichen, für ein Amazon/eBay/Facebook-Duplikat werden’s schon ein paar Dutzend mehr sein müssen. Entscheidend ist, dass alle zentralen Anwendungsfälle beschrieben werden. Im Zweifelsfall fragen wir dann sowieso bei euch nach.

1. Jeder Mensch kann User Stories schreiben. Man braucht dafür keine Ahnung vom technischen Background zu haben, wichtig ist nur, zu wissen, was man mit seinem Webauftritt erreichen will.
2. Der Aufwand, User Stories zu erstellen, lohnt sich allemal. Ihr werdet euch dessen bewusst, was ihr haben wollt. Wir wissen, was ihr von uns erwartet. Also die besten Voraussetzungen für ein für alle zufriedenstellendes Projekt.
3. Formuliert eure User Stories messbar. Also so, dass am Ende des Projekts zweifelsfrei gesagt werden kann, ob sie erfüllt sind oder nicht.

Das war’s auch schon. All die Infos kurz zusammengefasst sowie eine Excel-Vorlage für die Erfassung von User Stories gibt’s bei uns – einfach nachfragen!