3 schockierende Probleme mit User Stories, die jeder Product Owner unbedingt vermeiden sollte
„Als [Rolle] möchte ich [Funktion], um [Nutzen].“
User Stories, die so geschrieben sind, bergen drei große Probleme:
- Sie ignorieren den Kontext oder die konkrete Situation.
- Sie verwenden Personas.
- Sie koppeln die Funktion mit dem Ergebnis für den Nutzer.
Hier die Probleme im Detail:
Problem 1: User Stories ignorieren den Kontext oder die konkrete Situation.
„Als Nutzer möchte ich …“
Dazu fällt mir der englischsprachige Witz ein: only drug dealers and software companies call their customers ‘users’. Die Formulierung „als Nutzer“ ist bedenklich, wenn in einer User Story nicht näher beschrieben wird, welcher Nutzer gemeint ist. Im besten Fall ist sie überflüssig. Im schlimmsten Fall verschleiert sie, dass du nichts über den Nutzer weißt. Niemand kann dir einen Vorwurf machen, da selbst Mike Cohn in seinem Grundlagenwerk „User Stories Applied“ schreibt: „Ein Nutzer kann seinen Lebenslauf auf der Website veröffentlichen.“
Aber jetzt, wo du diese Tatsache kennst, solltest du die Formulierung ändern: Wenn du die Nutzer nicht kennst, dann solltest du zumindest „als Nutzer“ einfach weglassen. Besser ist es, wenn du die konkrete Situation beschreiben kannst, in der sich ein möglicher Nutzer befindet. Hierfür hilft dir dieses Format:
„Wenn …, dann möchte …“
Etwa:
„Wenn ein Webseitenbesucher mit dem Kundensupport spricht, dann möchte er …“
Problem 2: User Stories verwenden Personas.
Warte, du denkst vielleicht, Roman Pichler und Jeff Patton seien der Meinung, dass Personas und Stories in einer User Story hilfreich seien?
Allerdings ist es leicht, misszuverstehen, was sie wirklich damit meinen. Ein Fehler, den viele machen. Ich stimme Roman und Jeff zu, dass Personas ihren Stellenwert in agiler Produktentwicklung haben. Zum Beispiel, damit sich das Team besser in die Anwender seines Produkts einfühlt. Darüber hinaus helfen Personas dem Team auch, bessere User Interfaces zu designen.
Allerdings helfen sie dem Team nicht, die Kausalität oder Hintergründe einer User Story zu verstehen.
Nehmen wir an, die Persona Tom hat einen Snickers gekauft. Tom ist durch folgende Attribute genauer beschrieben:
- ist 32 Jahre alt und lebt in München
- hat einen Abschluss in BWL
- mag Erdnüsse, Schokolade, Nugat und Karamell
- liebt Snickers und isst einen pro Tag
- hat einen Hund
- ist sehr sportlich und pflegt einen aktiven Lebensstil
- hat sich den kleinen Finger gebrochen
- bestellt bei Amazon Kleidung und Schuhe
- sein Lieblingsrestaurant ist Hans im Glück
Nun, warum hat Tom den Snickers gegessen?
Um seinen Hunger zu stillen.
Alter, Geschlecht, Wohnort und Wochenendgewohnheiten einer Person erklären nicht, warum jemand einen Snickers-Riegel gegessen hat. Die Person hat 30 Sekunden Zeit, um etwas zu kaufen und zu essen und sich damit von ihrem Hunger zu erlösen.
Das bedeutet: Sind Personas nur durch demografische Attribute oder Kaufverhalten definiert, solltest du die Verwendung in der User Story überdenken. Was du als Product Owner wahrscheinlich kommunizieren willst, ist Kausalität!
Hier eignet sich die bekannte Formel aus Problem 1 besser:
„Wenn ich nur 30 Sekunden Zeit habe, etwas zu kaufen und zu essen, und für mindestens 30 Minuten satt sein möchte, dann möchte ich …“
Problem 3: User Stories koppeln die Funktion mit dem Ergebnis für den Nutzer.
Kommen wir nun zum schockierendsten Problem mit User Stories:
Mike Cohn schreibt in „User Stories Applied“: „Eine User Story beschreibt eine Funktionalität, die entweder für den Benutzer oder den Käufer eines Systems oder einer Software wertvoll ist.“
Das Problem:
Über die Hälfte der Features eines Produkts sind ein Flop. Wenn die User Story eine Funktion definiert hat, ist es schwierig, herauszufinden, warum sie fehlgeschlagen ist. Denn: In der Story ist die Implementierung mit dem Nutzen für den Anwender gekoppelt. Wie kann man aufgrund dieser Kopplung wissen, was falsch war? War die Umsetzung falsch oder waren die Annahmen über den Wert falsch?
Als wäre das nicht genug: Laut Gary Hamel behindern Product Owner, die solche User Stories erzählen oder sogar noch aufschreiben, die Innovativität eines Scrum Teams. Gary Hamel hat das Buch „Future of Management“ geschrieben. Um Garys Argument zu verstehen, musst du nicht sein ganzes Buch lesen, sondern seine Version der Maslowschen Bedürfnispyramide kennen. Sie beschreibt die Hierarchie der menschlichen Fähigkeiten im Arbeitsumfeld.
- Gehorsam: Mitarbeiter erscheinen und erledigen die Arbeit.
- Fleiß: Menschen arbeiten hart, konzentriert und machen Überstunden.
- Intellekt: Mitarbeiter übernehmen Verantwortung für ihre eigenen Fähigkeiten und führen Best Practices am Arbeitsplatz ein.
- Initiative: Mitarbeiter übernehmen Verantwortung für ein Problem. Sie ergreifen eine Gelegenheit, bevor man sie bittet. Sie tun dies, auch wenn sie nicht an die Beschreibung ihrer Funktion im Unternehmen gebunden ist.
- Menschliche Kreativität: Menschen, die sich fragen, wie man die Dinge grundlegend anders machen kann. Was kann man von anderen Branchen lernen? Wo liegen die Chancen für radikale Innovationen bei diesem Produkt oder dieser Dienstleistung?
- Leidenschaft und Eifer: Für diese Mitarbeiter ist ihre Arbeit nicht nur intellektuell, sondern auch spirituell bedeutsam. Ihre Arbeit ist für sie von enormer Bedeutung.
Nach Garys Auffassung sind die Ebenen 1 bis 3 eine globale Handelsware. Man kann diese menschlichen Fähigkeiten in jedem Niedriglohnland der Welt kaufen. Es gibt sicherlich kein Unternehmen in der westlichen Welt, dessen Kostenstruktur in der Lage ist, seinen Platz am Markt zu verteidigen, wenn dies alles ist, was es aus seinen Mitarbeitern herausholt.
Wenn Product Owner ihren Teammitgliedern eine gewisse Hierarchieebene zuordnen, wie viele ihrer Fähigkeiten bringen sie dann für das Unternehmen ein?
Wenn wir jetzt diese User Story betrachten:
„Als [Rolle] möchte ich [Funktion], um [Nutzen].“
Dann passiert genau das. Dieses Format schreibt Entwicklern die Funktionalität vor. Product Owner, die dieses Format verwenden, degradieren die Entwickler im Team somit auf die ersten 3 Stufen. Mehr noch: Sie behindern sie, Initiative zu ergreifen und die Verantwortung für die Lösung eines Problems zu übernehmen.
Der Product Owner ist kein Mini-CEO des Produkts!
Ich halte diese Beschreibung eines Product Owners für sehr bedenklich. Hier schwingt für mich immer mit, dass der Product Owner alles im Team bestimmt. Das ist aus Sicht des Scrum Guides nicht nur falsch, sondern behindert – wie wir von Gary lernen können – auch die Innovationsfähigkeit des ganzen Unternehmens.
Product Owner sind Produkt-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.
Möchtest du ein Produkt-Leader sein, dann solltest du niemals User Stories schreiben, die eine Funktionalität oder Aktion der Nutzer beschreiben. Stattdessen sollten sie deinem Team die Motivation oder das Ziel eines Nutzers erzählen.
Also nicht:
„Als Nutzer möchte ich nach Jobangeboten auf der Seite suchen.“
Sondern:
„Ich möchte ein für mich passendes Jobangebot bekommen.“
Oder:
„Ich möchte in Kontakt mit Unternehmen kommen, die Verstärkung suchen (und wissen, ob ich für das Unternehmen in Frage komme).“
Sind User Stories überhaupt noch zeitgemäß?
Produkt-Leadership ist schwer.
Typischerweise können Nutzer eben nicht ihre Wünsche, Motivation oder Ziele beschreiben, sondern schlagen Lösungen vor, welche sie bereits kennen. Steve Jobs hat dies bereits früh erkannt und es wurde in seiner Biografie von 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.“
Beißt sich hier die Katze nicht in den Schwanz?
Wenn User Stories die Geschichten von Nutzern erzählen, die Nutzer dir aber nur Featurewünsche nennen können und diese Wünsche die Innovativität der Entwickler behindern, warum werden User Stories dann überhaupt noch verwendet?
