Agilität
Kommentare 4

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.

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.

4 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.

Schreibe einen Kommentar

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