Agilität
Kommentare 6

Drei Missverständnisse rund um User Stories

Die User Story ist das vielleicht bekannteste Konzept aus agiler Softwareentwicklung. Leider ist es auch eines der am meisten missverstandenen Konzepte. Räumen wir mal mit den drei häufigsten Missverständnissen auf: User Stories sind nicht Bestandteil von Scrum, sie sind keine Mini-Spezifikationen und es ist nicht der Produkt Owner der sie schreibt.

User Stories sind Bestandteil von Scrum

Obwohl sich in Product Backlogs von Scrum Teams oftmals tatsächlich User Stories finden und Tools wie JIRA die Einträge im Backlog auch so nennen, erwähnt der Scrum Guide den Begriff User Story kein einziges Mal. Stattdessen ist dort nur von Product-Backlog-Einträgen als Überbegriff von Features, Funktionalitäten, Verbesserungen und
Fehlerbehebungen die Rede.

Tatsächlich stammt das Konzept der User Story aus dem Extreme Programming (XP), ein agiles Entwicklungsmodell, das maßgeblich von Kent BeckWard Cunningham und Ron Jeffries im Rahmen des C3-Projekts bei Chrysler zwischen 1995 und 2000 entwickelt wurde.

User Stories sind Spezifikationen

Gerade in Organisationen, die es über Jahrzehnte gewohnt waren, plangetrieben vorzugehen findet sich dieses Muster häufig. Es gibt Anforderer oder Kunden, die etwas wollen und Entwickler, die etwas liefern sollen. Damit die einen die anderen verstehen gab es früher dicke Konzepte und heute eben kleine User Stories. Was bleibt ist das schädliche Kunden-Lieferanten Anti-Pattern

User Stories heißen nicht ohne Grund so. Eine Story ist etwas, das man sich erzählt und über das man spricht. Eine User Story ist die Einladung zu einem Gespräch zwischen Nutzer und Entwickler und keine Spezifikation. Die Erkenntnisse dieser Unterhaltung werden natürlich festgehalten, aber diese Dokumentation ist nicht die Story.  

Ron Jeffries schlägt daher auch die Formel der drei Cs für gute User Stories vor: Card, Conversation und Confirmation. Mit Card ist einerseits gemeint, dass eine Story eine physische und im wahrsten Sinne begreifbare Repräsentation in Form eines Post-Its oder einer Karteikarte haben soll. Andererseits folgt aus dem begrenzten Platz auf einem solchen Zettel auch notwendigerweise Kürze und damit Unvollständigkeit. Diese Karte ist also nur der Anfang eines Gesprächs (Conversation). Wenn durch das Gespräch das gemeinsame Verständnis erzielt wurde, lässt sich dieses gut formal in Form von Akzeptanzkriterien (Confirmation) festhalten, welche dann die Grundlage für ein testgetriebenes Vorgehen bilden können.  

Der Product Owner schreibt die User Stories

Dieses Missverständnis findet sich oft in Kombination mit dem vorherigen. Das Kunden-Lieferanten Anti-Pattern verleitet dazu, wie bisher in klaren Verantwortlichkeiten und Übergaben zu denken. Das Entwicklungsteam ist verantwortlich für die Entwicklung und erwartet deshalb eine wasserdichte Spezifikation als User Story und die muss logischerweise der Product Owner als Stellvertreter der Nutzer liefern. Weil er das aufgrund der Fülle der Stories nicht alleine kann, führt das oft sogar zu ganzen Spezifikationsteams, die Stories für die Entwicklungsteams schreiben.

A user story is a promise for a conversation.

Alistair Cockburn

Wer die Story letztlich schreibt ist irrelevant, wenn man sich als ein Produktentwicklungsteam begreift, wenn man also das trennende Kunden-Lieferanten-Dogma abgelegt hat. Letztlich geht es eben nicht um die User Story als Artefakt und die Frage, wer dafür verantwortlich ist, sondern darum, dass Nutzer und Entwickler sich verstehen. Und dazu hilft es ungemein miteinander zu reden.

NEU: Das Manifest für menschliche Führung als Taschenbuch.

Taschenbuch Cover Manifest Zum ersten Jahrestag gibt es das Manifest für menschliche Führung nun in ausführlicher Fassung (inkl. Workshop-Format) als Taschenbuch bei Amazon (auch als E-Book erhältlich). Ich freue mich über Rezensionen und viele Empfehlungen an Freunde und Bekannte.

Buch Kaufen

Dir hat dieser Beitrag gefallen? Dieses Blog ist bewusst werbefrei, weil nur der Inhalt zählt. Wenn du deine Wertschätzung für diesen Beitrag zeigen willst, dann teile ihn wo auch immer. Und ich freue mich, wenn du mir einen Kaffee ausgibst! Denn in Anlehnung an das Zitat der Mathematiker Paul Erdős und Alfréd Rényi bin ich als Blogger auch nur eine Vorrichtung, um Kaffee in Artikel zu verwandeln!

Einen Kaffee ausgeben

Kategorie: Agilität

von

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

6 Kommentare

  1. Rainer Lührig sagt

    Vielen vielen Dank für diesen myth buster !
    Das gibt meinem miesen Gefühl mit der erlebten Handhabung von User Stories und Product Owner Ship Worte

  2. Heinz sagt

    Hallo Markus,
    Diese Antipatterns beobachte ich auch oft. Leider habe ich aber oft (zumindest bei organisatorischer Trennung von Fachbereich und IT) das Gefühl, dass nur die IT das Kunden-/Lieferantenebene durch Zusammenarbeit ersetzen will. Der Fachbereich will seine Kundenrolle behalten. Alles andere bedeutet nämlich mehr Arbeit und weniger Management-Kontrolle.
    Vielleicht stehe ich aber mit dieser Beobachtung alleine da.
    Vielen Dank für den Beitrag.

    • Danke für deinen Kommentar, lieber Heinz. Diese Trennung Fachbereich und IT fördert diese Kunden-Lieferanten-Beziehung natürlich – insbesondere wenn über Jahrzehnte eingeübt. Ich bin mir nicht sicher, wer da mehr in diesem Anti-Pattern verhaftet ist … ich erlebe Fachbereiche, die sehr engagiert mitarbeiten und das teilweise sogar im Team als Entwickler und ich erlebe IT, die nur mit perfekter Spezifikation arbeiten.

  3. Sebastian sagt

    Markus,
    vielen lieben Dank für den interessanten Artikel.

    Ich selbst darf mich stolz als Product Owner im Fachbereich bezeichnen :) – und wie schon richtig zusammengefasst: Ein Backlog-Eintrag ist eine Idee, die im gemeinsamen Gespräch (bei uns im Projekt in „3-Amigo-Sessions“ (PO, BA, Design, ggf. Dev)) vertieft werden. Ist das abgeschlossen, werden noch in Cucumber die Akzeptanzkriterien hinterlegt und so ist es sichergestellt, dass auch die richtigen Themen entwickelt werden (MVP lässt grüßen). Die Backlog-Priorisierung sorgt für die korrekte Priorität.

    Ein oft angetroffenes Problem ist, dass bis dato viele Stakeholder sich nicht so gerne mit den Details und Tiefen ihrer Wünsche auseinander setzen wollen – das ist ja zu viel Arbeit. Allerdings ist im großen Ganzen auch zu berücksichtigen; dass diese wertschaffende Vorarbeit viele nachgelagerte Prozesse/Themen deutlich vereinfacht.

    Ich sehe es als meine Mission, diese Involvierung zu vertiefen und so den Fokus auf die langfristige – und natürlich auch erfolgreiche – Weiterentwicklung des Produktes zur Mehrwertmaximierung zu richten.

    Als Product Owner ist Kommunikation nun mal der Schlüssel zum Erfolg – der den Unterschied zwischen einem erfolgreichen und erfolglosen Produktes ausmacht,

    Sebastian

    • Vielen Dank für deinen Einblick, Sebastian. Das klingt so, als hättest du da eine ganz gute Balance gefunden. Es ist für beide Seiten eine Umstellung: Für die Stakeholder / Anforderer genauso wie für die Entwickler; niemand kann einfach mehr auf den anderen zeigen und sich darauf zurückziehen, dass der erst mal die Arbeit machen soll. Es geht nur miteinander und genau darum geht es.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.