…und was du dagegen tun kannst.

User Stories sind eine weit verbreitete und gängige Praxis. Es wäre eine Zeitverschwendung, etwas darüber zu schreiben – zumindest dachten wir das. Unsere Erfahrungen in der Praxis zeigen aber ein anderes Bild:

Seit User Stories von Kent Beck (XP) vor gut 15 Jahren erstmals beschrieben wurden, sind diese heute populärer – aber gleichzeitig mehr missverstanden und fälschlich eingesetzt – denn je. Dies hat uns dazu bewogen, über die gängigsten Herausforderungen von User Stories zu schreiben.

Was sind User Stories – Grundgedanke hierzu

Was ist die Essenz einer User Story in der Theorie? User Stories…

  • … beschreiben das gewünschte Verhalten eines Software-Systems
  • … basieren auf einer Konversation zwischen den Anspruchsgruppen (Kunde, Fach, IT)
  • … beschreiben das WAS und nicht das WIE
  • … sind aus der Perspektive des Benutzers geschrieben und generieren Business Value
  • … fokussieren auf kleine, verdaubare Häppchen
  • … formulieren das Bedürfnis mit wenigen Worten (Story Card)

User Stories bestehen aus 3 wichtigen Merkmalen – die 3 C’s einer User Story (Ron Jeffries):

Story - 3 C's

Card

Folgende Informationen finden sich typischerweise auf ein User Story Card:

  • Kurzer Titel: Wähle einen Titel, der im Backlog leicht zu lesen und am Standup einfach zu erzählen ist
  • Beschreibung: Verwende das gängige Template in der Form „Als <Rolle>… möchte ich <Anforderung>… damit <Nutzen>.“
  • Zusatz-Informationen: Business Value, geschätzter Aufwand und Abhängigkeiten

Eine User Story besticht also nicht durch eine lückenlose Spezifikation. Sie dient als Grundlage für eine angeregte Diskussion, um ein gemeinsames Verständnis zu erhalten.

Gemeinsames Verständnis ist wichtiger als eine ausführliche Dokumentation

Conversation

Der weitaus wichtigste Aspekte ist die Konversation: Die User Story ist ein Versprechen über das Bedürfnis zu sprechen. Es reicht nicht auf einer Karte das Bedürfnis festzuhalten und dieses dann dem Team zur Umsetzung zu „übergeben“.

Stories entfalten ihre volle Wirkungsweise in der Erzählung und nicht durch eine Spezifikation der Funktionalität.

Confirmation

Bringe Sketches, Personas, Zeichnungen und was auch immer nützlich ist in die Diskussion ein. Diese Inputs helfen dir in der Diskussion zu einer Vereinbarung zu kommen, was gebaut werden soll. Beschreibe diese Vereinbarung als Set von Akzeptanztests.

Akzeptanzkriterien beschreiben das gemeinsame Verständnis zur Abnahme einer Story und schränken den Scope entsprechend ein.

Tipps: Beachte hierzu als Hilfestellung das Thema I.N.V.E.S.T.

5 Praxisfehler im Umgang mit User Stories

  1. User Stories beschreiben Anforderungen statt Bedürfnisse
  2. Abhängigkeiten / Schnitt
  3. User Story generiert Business Value, teilweise aber erst nach mehreren Sprints (weil sie zu gross sind)
  4. Diskussionen über wichtige Aspekte werden nicht geführt, Akzeptanzkriterien werden nicht hinterfragt
  5. Satztemplates sind ermüdend, man versteckt sich dahinter