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 Beck, Ward 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.