User Story KATA

Um die Qualität der User Stories in unseren mittlerweile 25 Scrum Teams bei Infonova weiter zu verbessern und anzugleichen führe ich gerade eine User Story KATA in unsere Entwicklungsabteilung durch. Ich habe die KATA mit Kollegen gestaltet und möchte die Idee dahinter gerne vorstellen:

Motivation:

Ausschlaggebend für einen erfolgreichen Sprint ist die Vorbereitung der User Stories. User Stories zu strukturieren ist einfach (siehe BDD), wie jedoch Product Owner und Team zu einem gemeinsamen Verständnis der Requirements kommen ist eine Herausforderung, die es zu jedes Mal aufs Neue zu meistern gilt. Als Check, ob ein gemeinsames Verständnis gegeben ist dient uns die Schätzung des Teams und die Definition of Ready. Wird eine User Story ohne ausreichendem gemeinsamen Verständnis commitet, passiert es nicht selten, dass das Commitment nicht gehalten werden kann, was die Planbarkeit eines Projektes schwierig macht. Bisher ist die Verwendung der DoR noch nicht über alle Teams etabliert. Mit Hilfe der KATA soll die Ausrollungen der DoR unterstützt werden und zu einer Qualitätssteigerung der Arbeitsweise führen.

Ziel:

  • Die Planbarkeit durch die Richtige Handhabung einer DoR und die daraus resultierenden geringeren Unterbrechungen und Scope-Changes im Sprint steigern.
  • Das kollaborative Erarbeiten der Requirements mit Product Owner und Team, sowie die Handhabung der Definition of Ready erlebbar machen und bewusst üben.

Vorbereitung:

Die Grundlage der KATA ist ein fiktives Business Szenario und eine dazu definierte User Story, jedoch ohne Akzeptanzkriterien, die in der KATA von den Teilnehmern ausgearbeitet werden sollen. Das Beispiel erscheint auf den ersten Blick bewusst trivial, enthält jedoch eine gewisse Komplexität, die nur durch genauere Beschäftigung mit der User Story zum Vorschein kommt.

Ablauf:

Es nimmt jeweils ein Entwicklerteam (4-6 Entwickler) + Scrum Master + Product Owner and der KATA teil. Alle Teilnehmer sind in der KATA in der Rolle des Entwicklerteams. Ich spiele in der KATA den Product Owner und stelle dem Team die vorbereitete User Story vor. In den folgenden 60 Minuten ist es die Aufgabe des Teams die User Story durch geschickte Fragen zu erforschen und die Akzeptanzkriterien in Form von Szenarien (siehe BDD) zu definieren. Nach und nach zeigt sich dem Team die wahre Komplexität der User Story. Nach einer Stunde breche ich diesen Prozess ab und lasse das Team das Ergebnis mit einer DoR auf die Erfüllung Dieser prüfen und schließlich die User Story zu schätzen.

Erfahrungen:

Nachdem ich nun mit 5 Teams die KATA durchgeführt habe kann ich ein erstes Zwischenresüme ziehen. Was den Teilnehmern der KATA meist zum ersten mal bewusst wird ist, wie wenig Zeit sie eigentlich für die Vorbereitung von User Stories investieren (meist weniger als 5% eines Sprints). Zum Anderen ist vielen die Bedeutung der DoR auf den Sprinterfolg noch nicht klar und wird durch die KATA erst richtig verstanden. Die teilgenommenen Teams können in der täglichen Arbeit auf die KATA als gemeinsames Erlebnis zurückblicken und so den sich langsam einschleichenden Prozess-Schlendrian entgegenwirken. Die Teilnehmer haben Spass an der KATA, was die wichtigste Grundlage ist, damit das transportierte Wissen auch weiterhin im Arbeitsalltag Anwendung findet.

Conclusio:

Zur Einführung von zentralen Prozess-Veränderungen, wie einer DoR scheint eine KATA hervorragend geeignet zu sein. Die aktive Einbindung der Mitarbeiter, der Spass-Faktor und das gemeinsame Erlebnis sind wesentliche Erfolgskriterien für nachhaltige Veränderung. Vermutlich wird jedoch die KATA nach einer gewissen Zeit wiederholt werden müssen um einen erneuten Impuls zu geben.

Wer an Details interessiert ist, bitte direkt an mich wenden.

User Stories richtig formulieren

In der agilen Softwareentwicklung hat sich das Arbeiten mit User Stories etabliert. Eine User Story beschreibt immer eine Kundenanforderung, den dahinter liegenden Business Case, so wie den Nutzen für den Anwender und dient als Ausgangspunkt für das Entwicklerteam, so wie für die Kommunikation mit dem Kunden, Entwicklern, Product Ownern, Auftraggebern, usw. Im optimalen Fall liegen bei der Erstellung von User Stories definierte Use Cases und Personas vor, die bei der Erstellung von User Stories als Hilfestellung dienen. Der erste Teil der User Story, die High-Level Beschreibung, beantwortet immer möglichst kurz und prägnant folgende Fragen: Wer will Was, Warum tun? (Mike Cohn, 2010) verwendet dafür folgendes Template:

Als <Benutzer / Rolle> möchte ich <ein Ziel> erreichen, damit <ein Nutzen> entsteht.

z.B.: Als Webshop-Kunde möchte ich Waren in einen virtuellen Warenkorb legen, damit ich diese zu einem späteren Zeitpunkt gesammelt betrachten kann.

Wer, Was, Warum möchte ist in dieser Form eindeutig und kompakt ausgedrückt. In der Praxis ist es daher sinnvoll sich an dieses Template zu halten um die drei W-Fragen zu beantworten. Viele Product Owner und Teams meinen jedoch eine noch bessere Variante gefunden zu haben um dies zu bewerkstelligen – meiner Erfahrung nach sind diese Abwandlungen jedoch meist entweder unvollständig in der Beantwortung der W-Fragen oder schlichtweg wesentlich länger in der Beschreibung und damit schlechter verständlich.

So weit, so einfach. Eine User Story soll aber neben der Kundenanforderung auch die notwendigen Details  für die Umsetzung enthalten. Dafür werden Akzeptanzkriterien definiert. Diese sollen Fragen über das Wie, Wann und Wohin beantworten. Sie sollen außerdem als Basis für automatisierte Testfälle dienen. Ich habe mir daher folgende Form bei der Definition von Akzeptanzkriterien angewöhnt:

  • Voraussetzung: Darin werden die notwendigen Vorbedingungen (z.B. Zustand der Software, aktueller Prozessschritt, Zustand der GUI,…) definiert.
  • Auslöser: Darin wird die Aktion (z.B. User Aktion, Eingehender Request, Triggern eines Events,…) beschrieben, die den Soll-Zustand triggert beschrieben.
  • Soll-Zustand: Beschreibt den vom Kunden gewünschten Soll-Zustand mit den notwendigen technischen Details.

Ein Akzeptanzkriterium für die oben definierte Webshop User Story könnte wie folgt aussehen:

  • Voraussetzung: Der Webshop-Kunde befindet sich auf der Produktseite XY und hat die Produktoptionen (Größe, Menge, Farbe) gewählt (siehe <Link zu Mockup 1>)
  • Auslöser: Der Webshop-Kunde klickt auf den Button “In den Warenkorb legen”
  • Soll-Zustand:
    • Der Kunde sieht den Warenkorb (siehe <Link zu Mockup 2>)
    • Das Produkt befindet sich mit den gewählten Optionen im Warenkorb (siehe <Link zu Mockup 3>)
    • Die Tabelle shopping_cart enthält die Produkte, die sich im Warenkorb befinden mit allen Optionen

In der Regel sind 5-10 Akzeptanzkriterien notwendig um das Verhalten der Software ausreichend zu beschreiben. Um den Kontext und die Details näher zu Beschreiben können Klassendiagramme, Systemarchitektur-Diagramme, Mockups, Screenshots, Sequenzdiagramme, Schnittstellendefinitionen, usw. verlinkt oder an die User Story angehängt werden. Ziel ist jedoch die User Story möglichst kompakt und übersichtlich zu halten um den Fokus zu bewahren. Im Zweifelsfall ist es besser eine große User Story in zwei kleine Stories aufzuteilen.

Quellen:

Mike Cohn (2010), Succeeding with Agile Software Development using Scrum, Addison-Wesley, Kap.13, S.239