User Stories schreiben, die wirklich Mehrwert liefern

Pragmatisches Projektmanagement

Herzlich Willkommen zu einer neuen Ausgabe vom Pragmatischen Projektmanagement, deiner Quelle für Informationen und Inspiration zu alltäglichen Herausforderungen im Management von Softwareentwicklungsprojekten. Dich erwarten Einblicke, Erfahrungen und unsere individuellen Ansichten zu Methoden, Werkzeugen, Vorgehensweisen und Fragen aus dem Leben eines Projektmanagers.

Gern diskutieren wir mit Euch auf LinkedIn zu Euren Erfahrungen und Ansichten.

„Wir kloppen einfach irgendwas ins Ticket, dann können die Entwickler anfangen.“
„Ich weiß nicht, was genau das bringen soll – aber der Kunde wollte das halt.“
„Das steht doch alles im Jira, warum reden wir überhaupt noch darüber?“

Klingt absurd? Leider Alltag. In vielen Teams sind User Stories zu Platzhaltern verkommen: oberflächlich, unklar, oft mehr Lösung als Problem. Aber gute Stories sind kein Selbstzweck. Sie sollen genau das Gegenteil bewirken: Klarheit schaffen, Diskussionen anstoßen, echten Nutzen sichtbar machen. Gute Stories sind kein Dokumentationsformat. Sie sind ein Denkwerkzeug. Ein Brennglas auf das, was wirklich zählt.

1. Was User Stories sind – und was nicht

User Stories stammen aus der agilen Welt und sind eigentlich ganz einfach gedacht: Kundennutzen sichtbar machen und die Entwicklung daran ausrichten. Nicht mehr, nicht weniger.

Aber oft mutieren sie zu:

• Technischen Tasks mit Anzug („Als Nutzer möchte ich, dass die API XY den Statuscode 200 zurückgibt…“)
• Designer-Wunschkonzerten („Ich will, dass der Button links unten animiert rausfliegt…“)
• Feature-Listen ohne Zusammenhang

Merke: Eine Story ist kein Pflichtenheft im Kleinformat. Sie ist ein Gesprächsanlass. Ein Denkwerkzeug. Ein Kompass. Kein Kochrezept.

2. Die Anatomie einer guten User Story

Jeder kennt den Klassiker: „Als [Rolle] möchte ich [Ziel], um [Nutzen] zu erreichen.“ Das klingt erst mal solide – fast wie aus dem Lehrbuch. Und dennoch wird damit regelmäßig gegen die Wand gefahren. Warum? Im besten Fall scheitert die Anwendung dieser pragmatischen Satzschablone an harmlosen Fehlinterpretationen. Im schlechteren Fall an fehlender Reife, Oberflächlichkeit oder schlichtweg schlechtem Handwerk.

In der Praxis stolpere ich immer wieder über symptomatische Fehlinterpratationen. Hier die Top-Fehltritte, die Teams sich gern mal leisten – und warum sie dir um die Ohren fliegen.

1. „Rolle“ wird ersetzt durch System oder Entwickler: „Als System möchte ich…“ – Das ist zumeist Bullshit-Bingo und hat mit Nutzerzentrierung genau gar nichts zu tun.
2. „Ziel“ wird zur Lösung degradiert: „…möchte ich ein Dropdown-Menü.“ – Aha. Und was genau soll das Dropdown lösen? Wenn schon die Lösung drinsteht, fehlt das Problem.
3. „Nutzen“ fehlt völlig oder ist leerer Buzzword-Container: „…um effizienter zu sein.“ – das gibt maximal Applaus von der Worthülsen-Polizei, aber hilft keinem Entwickler beim Umsetzen.
4. Technik statt Nutzen:: „Als Nutzer möchte ich, dass der JSON-Endpunkt optimiert wird…“ – Falsche Baustelle. Das ist kein Ziel, sondern interne Umsetzung.
5. Viel zu groß gedacht: Wenn deine Story sich anfühlt wie „Wir wandern mal eben über die Alpen“ – dann ist sie keine Story, sondern eine Expedition. Stories sollten wie Tagesetappen sein: gut planbar, überschaubar und mit erreichbarem Ziel.
6. Komplett unklar formuliert: „Als Kunde möchte ich das Produkt verbessern.“ – Danke für nichts. Was genau? Wie? Warum? Wer ist „Kunde“? Bitte gehe zurück auf Los.

Trotz dieser Abgründe hat die Satzschablone weiterhin ihre Daseinsberechtigung, denn sie hilft dir, drei entscheidende Fragen zu beantworten:

1. Wer profitiert davon? (Rolle)
2. Was will die Person wirklich erreichen? (Ziel)
3. Warum ist das wichtig? (Nutzen)

Erst wenn alle drei klar sind, lässt sich die Schablone sauber anwenden und die Aufnahme ins Backlog ist sinnvoll. Darüber hinaus erfüllen gute User Stories das INVEST-Prinzip, d.h. sie sind:

• 🦅Independent – möglichst unabhängig von anderen Stories
• 🤝 Negotiable – kein Vertrag, sondern Diskussionsgrundlage
• 💎 Valuable – liefert echten Mehrwert
• 📏Estimable – einschätzbar im Aufwand
• ⚖️ Small – überschaubar und im Normalfall innerhalb eines Sprints lösbar
• ✅ Testable – klar überprüfbar, ob sie fertig ist

Eine gute Story sagt dir nicht, was gebaut werden soll – sondern Warum. Sie spiegelt nicht den Wunsch des Nutzers, sondern sein zugrunde liegendes Bedürfnis. Und genau deshalb: Vorsicht bei technisch geprägten Product Ownern. Diese springen gern direkt in Lösungen. Dein Job ist es, im Problemraum zu bleiben – so lange, bis alle das Problem und den Mehrwert wirklich verstanden haben. Darüber hinaus gilt: Mehrwert ≠ Funktion.. Ein neuer Button im UI ist keine Story. Die Möglichkeit, durch diesen Button etwas Relevantes zu tun – das ist die Story.

3. Bessere User Stories schreiben – konkret, wirksam, gemeinsam

Du willst bessere Stories? Dann brauchst du mehr als ein Template und gute Absichten. Du brauchst Technik, den Willen, Dinge zu hinterfragen – und ein Team, das nicht einfach alles abnickt. Hier sind drei entscheidende Hebel:

1. Frag dreimal „Warum?“ – mindestens. Wenn dir jemand eine Anforderung präsentiert, frag nicht sofort, wie du das umsetzen kannst. Frag lieber dreimal: „Warum?“
   Warum will der Nutzer das? Warum ist das gerade jetzt wichtig? Warum ist das für das Ziel relevant? Diese Technik ist simpel, aber brutal effektiv: Sie bringt euch weg vom Feature-Geschwurbel und hin zum eigentlichen Bedarf.

Beispiel:
„Wir brauchen ein Dropdown-Menü mit Filterfunktion.“
Warum? – Damit man schneller etwas findet.
Warum ist das wichtig? – Weil die Liste zu lang ist.
Warum ist die Liste zu lang? – Weil alles in einem Screen angezeigt wird.
→ Vielleicht braucht ihr gar kein Dropdown, sondern ein besseres Layout? Oder eine neue Datenstruktur? Oder ein UX mit besserem Kontext?

2. Schreibe keine Story ohne Akzeptanzkriterien

Akzeptanzkriterien sind keine Bürokratie, sondern Verständnis-Checks und Qualitätsversprechen. Sie helfen euch zu prüfen, ob alle das Gleiche meinen – und ob ihr am Ende überhaupt merkt, dass ihr fertig seid.

Sie beantworten Fragen wie:

• Was muss passieren, damit die Story als erledigt gilt?
• Welche Rahmenbedingungen oder Einschränkungen gelten?
• Was darf explizit nicht passieren?

Eine User Story ohne Akzeptanzkriterien ist wie ein Vertrag ohne Unterschrift: Vielleicht gut gemeint, aber im Zweifel nicht belastbar.

Praxis-Tipp: Nutzt die Kriterien als Startpunkt für eure Tests. Gute Tests sind nichts anderes als gelebte Akzeptanzkriterien.

3. Fördere eine Kultur des Hinterfragens (statt Abnickens)

Die besten Stories entstehen nicht durch Genieblitze, sondern durch gute Diskussionen. Teams, die sich gegenseitig fordern, liefern bessere Ergebnisse. Das bedeutet:

• Entwickler, die nachfragen, anstatt nur zu bauen
• Product Owner, die offen für Kritik sind
• Stakeholder, die den Business Value auch selbst benennen müssen

Statt Stories einfach „abzunicken“, braucht ihr Mut zur Nachfrage. Nicht jede Story ist gut, nur weil sie im Refinement sitzt. Eine starke Teamkultur erkennt das – und arbeitet gemeinsam daran, sie besser zu machen.

Fazit:
Bessere User Stories beginnen mit einem echten Verständnis für das Problem. Sie sind klar, überprüfbar und stehen nicht für sich allein, sondern im Kontext eines Teams, das sich traut, nachzuhaken. Also: frag mehr, schreib weniger – und prüf, ob’s wirklich Sinn ergibt.

Im nächsten Teil unserer Serie geht es ums Geld in Form von Aufwand und wie wir Aufwände besser schätzen und planen können. Bis dahin freue ich mich auf Eure Reaktionen auf LinkedIn.