User Stories in Scrum

Written by Marvin Siegert

User Stories in Scrum

Monday, 31 August 2015 00:00

Anforderungen werden oft sehr technisch beschrieben. Dadurch entstehen Verständigungsprobleme zwischen den unterschiedlichen Unternehmensbereichen. Warum dokumentieren wir also nicht unsere Anforderungen aus Nutzersicht?
Bei der agilen Software-Entwicklung nach Scrum setzt Widas Concepts auf User Stories. Eine User Story dient dazu eine genaue Beschreibung eines Features aufzuzeigen und das aus Sicht der Person, die das Feature am Ende verwendet. Doch wie gestalte ich eine solche Benutzergeschichte?

1 7-W-Fragen

Grundsätzlich sollten darin die 7 W-Fragen beantwortet sein

  • Wer?
  • Was?
  • Wozu?
  • Wo?
  • Wann?
  • Wie?
  • Warum?

Die ersten drei sind dabei die wichtigsten.
Als  („Wer?“) möchte ich („Was?“), damit ich <Nutzen>(„Wozu?“)
Die Frage „Wo?“ steht für den Kontext. Wo in meiner Applikation soll die Funktion verfügbar sein.
Die Frage „Wann?“ steht für den zeitlichen Ablauf. Hier können Abhängigkeiten zu anderen Features oder gesetzliche Vorgaben eine Rolle spielen.

Die Antwort auf die Frage „Wie?“, soll beschreiben wie die Funktion umgesetzt werden soll. Hier kann man beschreiben wie genau man sich den Aufbau des Features vorgestellt hat. In Scrum ist es aber meistens üblich, dass das Team über das Wie entscheidet.
Die Frage „Warum?“ ist nicht gleichzusetzen mit „Wozu?“. Nach einem Nutzen fragt man mit „Wozu?“„Warum?“ ist die Frage nach dem Grund.
Ein möglicher Grund wäre bspw. eine gesetzliche Vorschrift.

2 Akzeptanzkriterien

Wenn man die Fragen beantwortet hat, ist dem Team schon ziemlich klar worum es geht und was am Ende herauskommen soll. Um diese Funktion exakt zu definieren und testbar zu machen, müssen als nächstes noch Akzeptanzkriterien (Erfolgskriterien) definiert werden. Ein Akzeptanzkriterium sollte dabei von genau einem Testfall abgedeckt werden können.
Beispiel:
Es wurde ein Haus aus Legosteinen gebaut
Dieses Erfolgskriterium kann je nach Idee genauen spezifiziert werden (Je nachdem wie sehr man das Team über das „Wie?“ entscheiden lassen will/kann)
Es wurde ein rotes Haus aus Legosteinen gebaut
Das Haus hat ein Flachdach
Das Haus ist mindestens 30 cm hoch
Mit diesen Angaben sollte ziemlich genau das herauskommen, was sich der Ideengeber (Kunde) vorgestellt hat.

3 Beispiel User Story von Smart City

Als ein Bewohner von Smart City, möchte ich durch das Herumtragen eines RFID-Chips

schlüssellos meine Haustür öffnen können.

Legofeuerwehr

 

 

 

Erfolgskriterien:

1. Es wurde ein Lego Haus mit einer Tür gebaut

2. Neben der Tür sind 3 LEDs (grün, gelb, rot) angebracht

3. Neben der Tür ist ein RFID-Lesegerät angebracht

5. Die grüne LED an der Tür zeigt an, wenn die Tür geöffnet ist

6. Die rote LED an der Tür zeigt an, wenn die Tür verschlossen ist

7. Die Tür öffnet sich für 5 Sekunden, wenn ein speziell codierter RFID-Chip in die Nähe kommt

8. Wenn ein falsch codierter RFID-Chip in die Nähe der Tür kommt, blinken die rote und die gelbe LED im Wechsel; 5 Sekunden lang

4 DoR – Defintion of Ready

Um eine Story abzunehmen hat jedes Team eine Defintion of Ready (DoR). Damit wird vermieden, dass Unklarheiten während des Sprints geklärt werden müssen und das Sprintziel nicht gefährdet ist.

Beispiel:

Definition of Ready (for Sprint)

1. Die Story ist vom Team vollständig verstanden

         a. Die Story trägt einen unterscheidbaren eindeutigen Titel

         b. Für Wen Was, Warum (Benutzergruppen/Personas/Fachentwickler etc.)

         c. Begrifflichkeiten sind eindeutig, Beschreibungen sind widerspruchsfrei

         d. Der „Nutzer“ des Story-(Teil)-Ergebnisses („Als x möchte ich…“)

            ist definiert

         e. Standard-Story-Pattern: „Als x möchte ich y, um z zu erreichen“

            bzw. x, y und z sind definiert

2. Die Story ist abnehmbar

         a. Erfolgskriterien sind eindeutig, messbar und durch Akzeptanztests prüfbar

            formuliert (Funktional + Nichtfunktional)

         b. Zwischen PO<->Team (DEV/UX) abgestimmt

3. Die Story ist schätzbar

         a. Besitzt mindestens eine Umsetzungsskizze

         b. Abhängigkeiten sind aufgezeigt (z.B. Ansprechpartner zur Abstimmung,

            andere Story)

         c. Den Teams wird überlassen wie Sie die Story technisch umsetzen unter

            Einhaltung der DoR und Erfolgskriterien

4. Die Story kann in einem Sprint abgeschlossen werden

         a. Die Komplexität der Story darf X Punkte nicht übersteigen

            (8-13 je nach Team)

         b. Abhängigkeiten sind berücksichtigt und ggf. Gegenmaßnahmen eingeleitet

5. Alle o.a. Informationen sind dokumentiert

         a. Alle Erfolgskriterien und Anforderungen und nötigen Dokumente sind in der

            Story hinterlegt bzw. verlinkt

         b. Kommentare dienen der Kommunikation, sind aber kein Bestandteil der Story

 

Eine dokumentierte User Story ist aber nicht der Hauptteil, sondern die dazugehörige Kommunikation zwischen dem Team und dem Product Owner.

5 Fazit

User Stories tragen nicht nur für ein einheitliches Verständnis bei, sondern zeigen gleichzeitig den Wert einer Aufgabe aus der Userperspektive auf – unserem Kunden. Zudem unterstreichen Sie die verbale Kommunikation und werden auch von Menschen ohne technischem Hintergrund verstanden.