5x bessere User Stories

User Stories sind Requirements, die aus der Perspektive eines Nutzers geschrieben werden. Sie dienen dazu, die Bedürfnisse der Nutzer zu erfassen und Anforderungen klar und nachvollziehbar für alle Beteiligten darzustellen. Im Endeffekt sind User Stories das eine Medium, wo man in der Realität meistens die unterschiedlichen Gewerke miteinander verbindet und sich abstimmt. Zum einen die Stakeholder, mit denen du zusammen die Requirements erarbeitest, die UXler und das Entwicklungsteam, was nachher diese Requirements in Form der User Stories umsetzt.

Da es bei der Erstellung von User Stories meistens ein großes Verbesserungspotenzial gibt, haben wir die - aus unserer Erfahrung - fünf größten Stolpersteine für User Stories für dich zusammengestellt.

#1: Wenn das WARUM nicht klar ist

Ein all-time Favorit. Manchmal weiß weder das Team noch der Produktmanager, warum sie die Story eigentlich implementieren. Und das kann unterschiedlichste Gründe haben.

Es gibt Organisationen, die sehr top-down sind und wo Lösungen nicht im Team entwickelt werden, sondern Anweisungen von oben befolgt werden.

Aber gerade das Entwicklungsteam ist eine rare Ressource im Unternehmen. Daher sollte immer vorab überlegt werden, warum das überhaupt gebaut werden sollte und was genau der Nutzen ist. Dann ist es auch einfacher für das Entwicklungsteam nachzuvollziehen, warum es Sinn macht, das eine oder andere zu bauen.

Hier können auch im Gespräch mit Stakeholdern einfache Fragen helfen, wie:

Warum braucht ihr das?

Habt ihr Daten, die uns helfen zu priorisieren?

Und deswegen ist die Frage, die du dir eigentlich immer als erstes stellen solltest, das WARUM. Das muss ganz klar sein. Das steigert nicht nur die Motivation, du kannst dir mit der Frage nach dem WARUM viel Frust und unnötige Arbeit sparen.

#2 Wenn nicht die Nutzersicht im Vordergrund steht

Die grundsätzliche Idee hinter einer User Story ist, dass diese aus Nutzersicht formuliert ist. Eine Anwendererzählung beschreibt informell eine gewünschte Softwarefunktion aus der Sicht des Nutzers.

I as … (WER), want to… (WAS) , so that… (WARUM)

Gerade am Anfang von den PM-Karrieren sehen wir relativ häufig, dass User Stories eher aus PM-Sicht geschrieben werden. Ich als PM hätte gerne folgendes Feature. Das ist der falsche Weg. Du musst dich in die Situation des Nutzers reindenken und dir wirklich überlegen, was der Nutzer möchte und wie eine User Story funktioniert. Der Satz: Ich als … möchte das …, um jenes Ziel zu erreichen, ist ja auch immer eine Prüfung. Habe ich wirklich das WARUM verstanden? Warum möchte überhaupt irgendjemand das haben und warum brauchen wir das?

Auch solltest du dir genau Gedanken machen WER wirklich der Nutzer ist. Nutzer oder User ist in der Regel zu breit gedacht: Also granularer werden und auf verschiedene Endkunden Personas segmentiert werden: Customer Service Agent, Marketing Manager, Vater, Mountainbike-Enthusiast…

#3: Wenn nur der Happy Path gesehen wird

Als PM, gerade am Anfang und das ist so einer der Gründe, warum Refinements mit Entwicklern sehr anstrengend werden, ist, dass man sich eigentlich nur über den Happy Path Gedanken macht. Aber das ist nicht ausreichend. Du wirst immer auf Probleme, Edge-Cases, stoßen und somit solltest du alle Eventualitäten in Betracht ziehen, bevor es wirklich in die Entwicklung geht. Beispiele für verschiedene Szenarien und Akzeptanzkriterien können dabei helfen, die unterschiedlichen Perspektiven und Bedürfnisse von Endbenutzern zu verdeutlichen.

Im Zweifel challenged dir das dein Team schon gut, aber es lohnt sich zumindest nicht komplett blank in ein Refinement zu gehen. Manche Edge-cases oder Herausforderungen machen nämlich dein ganzes Konzept oder deine ganze User Story un-implementierbar.

Hier ein paar Klassiker:

Welche Fehler können auftreten?

Was soll im Fehlerfall passieren?

Wie sehen Ladezustände aus?

Wie sehen leere Zustände aus (Keine Daten da)?‍

#4: Wenn die Kommunikation im Team fehlt

Nicht die eine Person refined die User Story. Refinements ist der Prozess, etwas durch kleine Änderungen zu verbessern. Und das geschieht nur im Team.

Das können nur Software-Entwicklerin sein oder es kann zum Beispiel auch kombiniert sein mit UXlerinnen. Es wird sich zusammengesetzt und über die Requirements gesprochen, Fragen gestellt, Anregungen ausgetauscht.

Die User Stories werden im Endeffekt mit dem Input aus dem Entwicklungsteam gefüttert. Eine User Story ist eine Diskussionsgrundlage und wenn darüber nicht mit dem Team diskutiert wird, dann ist die Wahrscheinlichkeit ziemlich hoch, dass viele Rückfragen kommen während der Implementierung. Diese Fragen gilt es zu klären, bevor das Produkt in die Entwicklung geht. Der Aufbau der User Story, bestehend aus mehreren Teilen, ist entscheidend für die klare Kommunikation und das Verständnis der Anforderungen der Nutzer. Das heißt also, ein gutes Refinement ist auch ein massiver Zeitsparer auf lange Sicht.

#5: Wenn der Outcome vernachlässigt wird

Eine Diskussion im Produktmanagement ist häufig: Wie liefern wir nicht nur Output, sondern auch Outcome? Zur Verdeutlichung haben wir ein kleines Beispiel für dich.

Nehmen wir das Beispiel einer Pizza Bestellung und Lieferung. Die Bestellung ist die User Story. Am Telefon nimmt jemand die Bestellung entgegen (Du als PM), gibt sie dann an den Pizza Bäcker (Entwicklungsteam) weiter. Dann gibt es vielleicht noch ein, zwei Rückfragen, dann wird die Pizza gemacht, dann geht sie zu demjenigen, der ausliefert und dieser übergibt die Pizza (Das ist in unserem Fall die digitale Delivery). Und that’s it. Der Output ist die Pizza. Das, was eigentlich ausgespart wird, ist der entscheidende Schritt danach. Nämlich: Wie hat dem Kunden denn die Pizza geschmeckt? Der Outcome sollte in dem Fall ein satter, glücklicher Kunde sein.

Eine User Story ist eine kurze und informelle Beschreibung einer Softwareanforderung aus der Perspektive des Endnutzers, um dessen Bedürfnisse klar zu erfassen. Dem Outcome wird vor allem im digitalen Bereich zu selten Beachtung geschenkt. Es wird sich zu wenig vor der Implementierung überlegt, welche Daten gesammelt werden können, um den Erfolg messbar zu machen. Wie kann gezeigt werden, dass das Produkt oder die Leistung wirklich einen Impact haben? Wie messen wir in einem Monat, in zwei Monaten, je nach Laufzeit, ob das wirklich erfolgreich war?

Der Outcome, hat enormen Einfluss auf den Erfolg des Produktes. Die Sammlung von Daten zur Messung des Erfolges und deren Ergebnisse werden im besten Fall sehr befriedigend für dein Team sein und sind für dich als Produktmanager auch eine gute Informationsgrundlage dem Management gegenüber.

Alle 5 auf einen Blick

Erkunde das WARUM und du bist auf der sicheren Seite. Dann stelle sicher, dass die Nutzersicht im Vordergrund steht. Denke auch über Probleme nach und ziehe nicht nur den Happy Path in Betracht. Es gibt immer Edge Cases, die auftreten. Eine User Story ist eine Diskussionsgrundlage. Gute Requirements entstehen im Team und durch hinzuziehen aller Perspektiven. Deshalb ist die Kommunikation im Team definitiv ein ganz entscheidender Erfolgsfaktor. This is the tricky bit, weil es eine gute Planung und regelmäßige Reflektion benötigt. Messe den Outcome, nicht nur den Output. Mache in deiner User Story schon klar, wie du Erfolg messen möchtest und überprüfe regelmäßig ob dieser Erfolg auch eintritt.

Eine User Story ist per Definition eine kurze Darstellung einer gewünschten Softwarefunktion, die aus der Sicht des Nutzers verfasst wird. Diese Definition dient als Grundlage für das Verständnis und die Erstellung effektiver User Stories.

Wenn du all diese Aspekte beachtest, wird dies zu einer erheblichen Verbesserung deiner User Stories führen.

‍