| Was | eine Software-Anforderung in Alltagssprache formuliert (eine Erzählung aus Anwendersicht) |
| Wer | verantwortlich: Product Owner (PO) – um zu diskutieren mit: DEV (Developer) Team |
| Wann | während dem Sprint, spätestens beim Sprint Planning |
| Wieso | um rasch Anforderungen (bewusst kurz) festzuhalten und zusammen mit Akzeptanztests zur Spezifikation einsetzen > Gespräch mit PO zur Anwendersicht! |
| Zweck | soll vermeiden, dass DEVs blockiert sind (zügiger arbeiten können, weil keine Blocker während dem Sprint auftreten sollen) |
#1 User Story skizzieren – Kriterien erfüllen
Jede User Story sollte die INVEST-Kriterien erfüllen, um die Qualität einer Story zu gewähren:
- Independent
Story muss unabhängig von anderen User Storys sein: sie darf nicht davon abhängen, dass zuerst eine andere Story umgesetzt werden muss - Negotiable
Storys sind niemals fix: PO, Stakeholder und Team diskutieren und präzisieren sie gemeinsam - Valuable
die Story soll nicht nur einen Nutzen haben, sondern muss auch einen eindeutigen Mehrwert bieten - Estimatable
der Aufwand zur Umsetzung einer Storys muss für das Team schätzbar sein - Small
Storys sollten weder zu groß noch oder zu klein sein: der konkrete Umfang einer Story sollte vom Team entschieden werden (es wird empfohlen, dass die Umsetzung 1 Story mind. 0,5 PT und max. 10 PT dauern sollte) - Testable
eine Story muss zwingend testbar sein, um diese auch erfolgreich abschließen zu können
#2 User Story schreiben – Format einhalten
As a <Persona/who>
I want to <Need/what>
so that <Reason/why>Beispiel User Story
Als Käufer eines Online-Shops
möchte ich das ausgewählte Produkt mit meiner Mastercard bezahlen,
damit ich ohne viel Aufwand den Bestellprozess abschließen kann.
#3 User Story ergänzen – Akzeptanzkriterien anführen
Akzeptanzkriterien sind Abnahmekriterien, die die Anforderung konkretisieren. Dh sie definieren Bedingungen, durch die eine Anforderung erfüllt und vom Stakeholder (Anwender, Nutzer, Kunde, PO) akzeptiert wird.
Zweck = möglichst eindeutig und objektiv zu bestimmen, ob eine Funktionalität genauso beschaffen ist, wie es sich der Stakeholder vorstellt (“Confirmation of Satisfaction”).
Beispiel Akzeptanzkriterien
- Hat der Online-Shop-Besucher Produkte im Warenkorb, sollte der “Jetzt kaufen” Button aktiviert sein.
- Sobald alle Pflichtfelder (Name, Anschrift, E-Mail, Telefonnummer, Zahlungsmethode) ausgefüllt wurden, soll die Zahlungsmethode “Zahlen mit Mastercard” ersichtlich werden.
- Wurde “Zahlen mit Mastercard” ausgewählt, muss die Kartennummer, das Gültigkeitsdatum sowie die Secure Nummer eingetragen werden und diese Kombination auf Gültigkeit gecheckt werden.
#4 User Story schätzen – mit Team diskutieren
| T-Shirt Sizes | Story Points | Beer Points |
|---|---|---|
| XS | 1 | 0,2 (Pfiff) |
| S | 2 | 0,3 (Seidel) |
| M | 3 | 0,5 (Halbe) |
| L | 5 | 1 (Maß) |
| XL | 8 | 3 (6er-Tragerl) |
| XXL | 13 | 10 (Kiste) |
| 20 | 30 (Fass) | |
| 40 | 50 (großes Fass) | |
| 100 |