User Stories sind dann sinnvoll, wenn eine Funktion umgesetzt werden soll, bei der noch nicht klar ist, wie sie in der Software eigentlich genau aussehen soll. Eine gute User Story beinhaltet neben der eigentlichen User Story (Who, What, Why) und den Akzeptanzkriterien alle weiteren für die Umsetzung notwendigen Informationen, wie Status, ID, Verantwortlicher etc.
Akzeptanzkriterien beinhalten alles, was notwendig ist, damit das Team weiß, welche Bedingungen die fertige Software erfüllen muss, damit der PO die Story abnimmt. Dazu kann (aber muss nicht!) gehören:
- UI Mockups
- Ablaufverhalten im Detail und Fehlerverhalten
- Beschreibung benötigter Daten
- Business Logik (Berechnungen, Formeln, Regeln, Berechtigungen, …)
- Funktionsspezifische nichtfunktionale Anforderungen
- Randbedingungen (technisch, fachlich)
- Alle möglichen sonstige Hinweise für die Entwickler
- Testdaten und Demoszenarien für die Abnahme
Oft können Akzeptanzkriterien nach dem „Wenn … dann …“ Schema formuliert werden, um auch Sonderfälle und Varianten zu berücksichtigen. User Story und Akzeptanzkriterien müssen, wie alle anderen Anforderungen auch, verständlich, eindeutig und vollständig formuliert werden. Achten Sie darauf, dass jedes Akzeptanzkriterium einzeln referenzierbar ist, z.B. indem sie diese nummerieren. Akzeptanzkriterien sollten auch immer die Frage beantworten „Was möchtest Du im Review-Meeting sehen, damit Du die Story abnimmst?“.
Bevor Sie loslegen, überlegen Sie gemeinsam mit Team und PO, welche Informationen Sie je Story brauchen, damit das Team den Aufwand optimal schätzen und die User Story umsetzen kann.
