User Stories – Ermittlungs- oder Dokumentationstechnik? TEIL III: Abnahmekriterien und das Hinterfragen von User Stories

Nach den Grundlagen in Teil I  und den gängigen Qualitätsmaßstäben für User Stories in Teil II  beschäftigen wir uns in diesem Teil der Blogserie zur unterstützenden Technik „User Stories“ mit Abnahmekriterien und einer Fragetechnik, die es erlaubt, die Hintergrundinformationen zu ermitteln, die zum Verständnis (und damit für die erfolgreiche Umsetzung!) einer User Story notwendig sind.

Abnahmekriterien, auch manchmal als „Akzeptanzkriterien“ (vom englischen acceptance criteria) bezeichnet, dienen zur Dokumentation der Aspekte, die der jeweilige User Story-Verantwortliche für wichtig erachtet, damit er mit der Umsetzung seiner User Story zufrieden ist. Ein festes Format gibt es für Abnahmekriterien nicht, allerdings wird oft ein Aufbau verwendet, der einem Testfall oder Szenario ähnelt, das Given-When-Then-Schema, hier in übersetzter Form:

Angenommen <hier folgen die geltenden Voraussetzungen>,
Wenn <hier folgen eine/mehrere Aktionen des Benutzers>,
dann <hier folgen die geforderte(n) Reaktion(en) des Systems>.

Die geltenden Voraussetzungen, Benutzeraktionen und Reaktionen des Systems können von einigen Parametern bis hin zu komplexen Szenarien reichen, und eine User Story kann (und wird in den meisten Fällen) mehrere Sets dieser Abnahmekriterien besitzen.

Abnahmekriterien nach dem Given-When-Then-Schema unterstützen die testgetriebene Entwicklung (TDD) und stellen sicher, dass der Kunde ein klares Bild davon hat, was er genau möchte. Das Given-When-Then-Schema ist allerdings nicht zwingend erforderlich. Solange allen Beteiligten klar ist, worum es geht, und was getan werden muss, um die User Story zu implementieren, ist die Dokumentationsform irrelevant.

Als weitere Methode, um zu guten User Stories zu kommen, wird auch die Ursprungsursachenanalyse (root cause analysis), bzw. “5 Warums“ (5 Whys) genannt – das bis zu fünfmalige Hinterfragen der gewünschten Funktionalität oder Eigenschaft mit der Frage „Warum?“. Die Anwendung dieser Methode beherrscht schon jedes Kind nahezu perfekt… nur dass Kinder sich selten auf fünfmal Fragen beschränken.

Ein Beispiel zur Anwendung der Ursprungsursachenanalyse für User Stories findet sich in Cory Foys Blog [1]

Entwickler: Warum muss das System mit mehrfachen Zuordnungsanfragen umgehen können?
Kunde: Weil einige Bestellungen aufgeteilt werden müssen.
Entwickler: Und warum müssen sie aufgeteilt werden?
Kunde: Weil nicht alles auf eine Palette passen wird.
Entwickler: Warum wird nicht alles drauf passen?
Kunde: Weil wir nur eine bestimmte Anzahl von einem Gegenstand auf eine
einzelne Palette packen können. Es gibt nur begrenzt Platz um das Zeug sicher zu stapeln.
Entwickler: Und warum beeinflusst das das System?
Kunde: Weil wir nicht wollen, dass Kunden über die Palettenaufteilung nachdenken müssen. Wir wollen, dass sie einfach ihre Bestellung aufgeben können und das System errechnet, wie viele Paletten dafür benötigt werden.

Sind User Stories nun eher eine Ermittlungstechnik oder eine Dokumentationsform? Eine Antwort könnte lauten: Ein bisschen von beidem. Was denken Sie dazu? Wir freuen uns über Mail zu Ihren persönlichen Erfahrungen mit User Stories an heureka@sophist.de.

Quellen:
[1] http://blog.coryfoy.com/2011/03/breaking-down-features-to-user-stories/

Hinterlasse eine Antwort

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


eins + = 3

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>