User Storys – wenn der Schaden größer als der Nutzen ist
User Story 1: Als Nutzer möchte ich den Kundensupport im Chat kontaktieren, um meine Frage zu klären.
User Story 2: Als Käufer möchte ich meine vorherigen Bestellungen einsehen können, um eine neue Kaufentscheidung zu treffen.
Abstrahiert ergibt sich die folgende Formel für den Aufbau von User Storys:
Als [Rolle] möchte ich [Funktion], um [Nutzen].
User Storys dieser Art bergen jedoch häufig drei große Probleme, die die Entwicklung von Produkten erheblich behindern oder in eine Sackgasse manövrieren können.
- Problem 1: Der Kontext und/oder der konkrete Anwendungsfall werden ignoriert.
- Problem 2: Für den Anwendungsfall werden bedeutungsleere Personas verwendet.
- Problem 3: Die Funktion wird direkt an das Ergebnis für den Nutzer gekoppelt.
Gerne möchte ich nachfolgend beleuchten, was diese Probleme konkret für Ihre Produktentwicklung bedeuten können und warum sie unbedingt vermieden werden sollten.
Problem 1: User Storys, die Kontext und den konkreten Anwendungsfall außer Acht lassen
Schauen wir uns nochmal die Ausgangsbeispiele an:
User Story 1: Als Nutzer möchte ich den Kundensupport im Chat kontaktieren, um meine Frage zu klären.
User Story 2: Als Käufer möchte ich auf meine vorherigen Käufe hingewiesen werden, um eine neue Kaufentscheidung zu treffen.
User Story 1 lässt uns völlig im Unklaren, um welchen Nutzer es sich handelt. User Story 2 macht es vermeintlich besser, doch auch hier wird kein konkreter Anwendungsfall oder Kontext benannt. Handelt es sich um einen regelmäßigen oder Alt-Kunden? Kauft er stets dasselbe Produkt oder möchte er etwas Neues finden, Angebote vergleichen oder Ware reklamieren?
Die Formulierung “Nutzer möchten” sollte man als Product Owner stets hinterfragen. Sie ist immer dann bedenklich, wenn in der User Story nicht näher beschrieben wird, welcher Nutzer konkret gemeint ist. Dann verschleiert sie, dass gar nichts über den Nutzer bekannt ist. In einem solchen Fall besteht Klärungsbedarf.
Es lohnt sich jedoch auch immer zu fragen: Ist die Rolle des Nutzers für diese User Story überhaupt notwendig oder genügt die Beschreibung eines konkreten Anwendungsfalls? Nicht selten werden Sie sich so helfen können. So lässt sich bspw. die User Story 1 sinnvoller formulieren:
“Wenn ein Webseitenbesucher mit dem Kundensupport in Kontakt tritt, dann möchte er…”
Sicher ist: Eine leere Rollenbezeichnung wie “Nutzer” oder “Käufer” vorzuschieben, wird dazu führen, dass im Entwicklungsvorgang kein gemeinsames Verständnis für den Use Case entsteht.
Problem 2: User Storys, die auf Personas aufbauen
Direkt vorweg: Personas erfüllen ohne Frage eine wichtige Funktion innerhalb agiler Produktentwicklung. Sie ermöglichen dem Team, sich in die Anwender des Produktes einzufühlen und helfen ganz entscheidend z.B. bei der Erstellung eines passenden User Interfaces.
Im Hinblick auf User Storys sind Personas dennoch fehl am Platz: Sie helfen uns i.d.R. nicht dabei, Kontext und Kausalität eines konkreten Anwendungsfalls zu verstehen.
Nehmen wir an, ein Käufer hat einen Müsliriegel gekauft. Für unseren Shop ist die Nutzer-Persona “Hannes” folgendermaßen definiert:
Hannes
- ist männlich, 42 Jahre alt,
- unverheiratet und lebt in Berlin,
- hat einen Abschluss in Psychologie und arbeitet in einer Agentur,
- ist laktose-intolerant,
- liebt Snacks für unterwegs und isst einen Riegel pro Tag,
- hat einen Hund,
- ist sehr sportlich und pflegt einen aktiven Lebensstil,
- bestellt Kleidung und Schuhe online und
- isst regelmäßig Sushi.
Warum hat Hannes den Müsliriegel gekauft? Um unterwegs seinen Hunger zu stillen.
Die Kausalität der Kaufsituation “Ich bin unterwegs, verspüre Hunger und muss mich in wenigen Sekunden für einen Kauf entscheiden, der mich für die nächste Stunde satt macht” ergibt sich aus der konkreten Situation, lässt sich jedoch mit keinem der anderen Attribute, die Hannes innerhalb der Persona zugeordnet werden, begründen.
Genauso hätte sich diese Kaufentscheidung für die ganz anders definierte Persona “Steffi” (56 Jahre alt, verheiratet, Lehrerin, eher unsportlich, lebt in Ulm) ergeben.
Es sind für diese User Story also nicht die vorliegenden Personas von Nutzen, sondern auch hier hilft die Beschreibung des konkreten Falls weiter:
“Wenn ich unterwegs bin, Hunger habe und schnell etwas kaufen möchte, das mich für eine Stunde satt macht, dann möchte ich …”
Problem 3: Die Funktion wird an das Ergebnis für den Nutzer gekoppelt
Verknüpfen wir Funktion und Ergebnis für den Nutzer zu einer Einheit wie in unserem Beispiel:
User Story 1: Als Nutzer möchte ich den Kundensupport im Chat kontaktieren, um meine Frage zu klären.
Also: “Der Chat mit dem Kundensupport klärt die Nutzerfrage”, dann laufen wir Gefahr, uns in eine Sackgasse zu manövrieren.
Wir müssen bedenken: Mehr als die Hälfte der Features eines Produkts erweisen sich schließlich als Flop. Wenn die User Story nun eine Funktion definiert, die an den Nutzen für den Anwender gekoppelt ist, wird es schwierig oder vielleicht auch unmöglich, im Nachhinein herauszufinden, warum diese Implementierung gescheitert ist. Durch die Verknüpfung ist erst einmal nicht zu erkennen, was falsch war.
Liegt es an der Umsetzung oder waren die Annahmen über den Wert falsch?
Und es geht noch weiter: Dass sich unpassend verknüpfte und zu sehr auf konkrete Features ausgerichtete User Storys negativ auf die gesamte agile Produktentwicklung auswirken können, zeigt der abschließende Abschnitt.
User Storys, die eine innovative Produktentwicklung verhindern
Es zeigt sich, dass neben den Problemen, die ein inhaltsleerer Nutzerbegriff und fehlerhafte Kopplungen innerhalb der User Storys mit sich bringen, die Versteifung auf konkrete Produktfunktionen eine innovative Produktentwicklung ausbremsen oder verhindern.
Betrachten wir noch einmal die schematisierte User Story:
Als [Rolle] möchte ich [Funktion], um [Nutzen].
Dieses Format schreibt Entwicklern die Funktionalität vor. Product Owner, die es verwenden, degradieren die Entwickler zu rein ausführenden Teammitgliedern. Sie behindern sie dabei, Initiative zu ergreifen und die Verantwortung für die Lösung eines Problems zu übernehmen.
In einer solchen Konstellation fungiert der Product Owner häufig wie eine Art “Mini-CEO” des Produkts. Diese Beschreibung der Rolle des Product Owners ist bedenklich und es sollte hinterfragt werden: Ist der Product Owner derjenige, der letztlich alles bestimmt? Das wäre aus Sicht des Scrum Guides nicht nur falsch, sondern behindert auch die Innovationsfähigkeit des ganzen Unternehmens.
Product Owner sind vielmehr Product Leader. Als Leader führen sie an, indem sie Freiraum geben, damit sich die Entwickler kreativ einbringen können, um die Lösung zu finden, die Nutzer wirklich begeistert.
Wer ein Product Leader sein möchte, sollte niemals User Storys schreiben, die eine bereits bekannte, gelernte Nutzer-Funktion beschreiben. Stattdessen sollten sie ihrem Team die Motivation oder das Ziel eines Nutzers nahe bringen.
Also nicht: “Als Nutzer möchte ich nach Jobangeboten auf der Seite suchen.”
Sondern: “Ich möchte ein für mich passendes Jobangebot erhalten.”
Oder: “Ich möchte mit Unternehmen in Kontakt kommen, die Verstärkung suchen (und wissen, ob ich für das Unternehmen in Frage komme).”
Typischerweise werden Nutzer nicht selbst ihre Wünsche, Motivation oder Ziele auf diese Art beschreiben, sondern Lösungen vorschlagen, die sie bereits kennen. Steve Jobs hat dies bereits früh erkannt und es wurde in seiner Biografie durch Walter Isaacson auf den Punkt gebracht¹:
“Manche Leute sagen: ‘Gib den Kunden, was sie wollen.’ Aber das ist nicht mein Ansatz. Unsere Aufgabe ist, herauszufinden, was sie in der Zukunft wollen werden, bevor sie es überhaupt tun. Ich glaube, Henry Ford hat einmal gesagt: ‘Wenn ich die Kunden gefragt hätte, was sie wollen, hätten sie mir gesagt: Ein schnelleres Pferd!’ Die Menschen wissen nicht, was sie wollen, bis man es ihnen zeigt. Deshalb verlasse ich mich nie auf die Marktforschung. Unsere Aufgabe ist es, Dinge zu lesen, die noch nicht auf dem Papier stehen.”
In diesem Sinne gehört es zur Aufgabe des Product Owners, sich dieses Fakts bewusst zu sein und sich weniger an bekannten Features, sondern mehr an einer Produktvision zu orientieren. Diese dann in User Storys zu verwandeln, die es dem gesamten Team ermöglichen, ein gemeinsames Verständnis zu entwickeln, aus dem innovative Lösungen entstehen können, ist die Herausforderung, die die Bedeutung des Product Leaders ausmacht.
Hinweise:
[1] Steve Jobs: Die autorisierte Biografie des Apple-Gründers
Wenn Sie sich für Scrum.org-Trainings bei Simon Flossmann, z. B. zum Professional Product Owner™ (Advanced), Professional Scrum Master™ (I+II) oder Agile Leadership™ (Essential+Evidence Based Management), interessieren, dann schauen Sie gerne bei Trainings von Colenet.de vorbei.
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Simon Flossmann hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:
Von der Feature-Roadmap zur Outcome-Roadmap
Abhängigkeiten in Scrum eliminieren
Simon Flossmann
Simon Flossmann ist ein erfahrener Scrum-Praktiker und arbeitete von Start-ups bis hin zu großen Konzernen in einer Vielzahl von Branchen. Als Professional Scrum Trainer bei Scrum.org hilft er Scrum Master, Product Owner und Agile Leader dabei, Scrum umzusetzen, um effektiver zu arbeiten.
Aufgrund seines tiefen Wissens und seiner Erfahrung in der Arbeit mit mehreren Scrum-Teams ist Simon Flossmann einer der beiden Stewards des Scaled Professional Scrum Trainings und hilft dabei, den Kurs weiterzuentwickeln und die Integrität von Ken Schwabers Vision zu Scrum zu bewahren.