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

Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Agile coach from Graz, Austria. I have been working in the software industry since 2006, being an agile practitioner since 2011. I have experience with pioneering Agile, transitioning teams from waterfall to Agile, as well as working with established high performance teams within scaled agile enterprises. I worked with co-located as well as with dispersed teams, in start-ups, medium sized companies and big global enterprises in various industries. Currently I am working as enterprise Agile coach at AVL List GmbH.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s