Die Definition einer User Story in SCRUM

Ziele der User Story

Nur allzu oft wird bei neuen Anforderungen der Endnutzer vergessen. Der Fachbereich möchte etwas umgesetzt haben, ohne dabei vorab genau zu prüfen, ob es auch das ist, was der Nutzer benötigt. User Stories versuchen genau diesem Umstand entgegenzuwirken. Denn bereits bei den ersten Überlegungen für die neue Umsetzung steht immer der Nutzer im Vordergrund, denn er ist es auch, der das Produkt letztlich nutzen soll.

Beschreibung:

• Gerüst

Als (Anwendertyp)
möchte ich (Aktion),
um (Ziel) zu erreichen

• Beispiel: Als nicht-eingeloggter User möchte ich, mich für einen Newsletter registrieren können, um über aktuelle Firmeninformationen informiert zu werden.

• EPIC versus User Story

  • Ein Epic ist dem Grunde nach eine übergeordnete User Story. Ein Epic kann somit aus verschiedenen User Stories bestehen. Dies eignet sich besonders dann, wenn eine User Story zu groß ist und diese in kleinere User Stories heruntergebrochen werden muss.

• INVEST-Kriterien

  • I – Independent: Eine User Story soll unabhängig anderer User Stories sein. Somit können diese unabhängig voneinander umgesetzt werden ohne Abhängigkeiten
  • N – Negotiable: Lassen sie bewusst Raum für Diskussionen. Der Fachbereich beschreibt die Anforderungen grob, die genaue Ausformulierung der User Story erfolgt im Anschluss im Team
  • V – Valuable: User Stories ohne Mehrwert sollen nicht umgesetzt werden. Eine User Story die keinen Mehrwert liefert, sollte auch erst gar nicht umgesetzt werden
  • E – Estimable: Die User Story darf nur die Größe besitzen, sodass sie überschaubar und für die Entwickler testbar ist
  • S – Small: Generell sollen die User Stories vom Umfang der Umsetzung nicht zu groß sein – aber auch nicht zu klein. Sollten die User Stories vom Umsetzungsaufwand zu groß sein, so sollten diese lieber in kleinere User Stories gesplittet werden. Als Faustregel hat sich gezeigt, dass eine User Story nicht größer 20% der gesamten Sprintlänge sein soll
  • T – Testable: Die User Story muss testbar sein ansonsten kann sie nicht abgenommen werden. Hierbei geht es nicht darum, die gesamte Funktionalität zu testen (bspw. die komplette Strecke der Newsletteranmeldung) sondern den in der User Story explizit beschriebenen Umfang

• Akzeptanzkriterien

  • Jede User Story muss mit sogenannten Akzeptanzkriterien versehen werden. Die Akzeptanzkriterien definieren, wann eine User Story als erledigt angesehen werden kann. Welche nicht-technischen Eigenschaften müssen gegeben sein, damit die User Story geschlossen werden kann.

Vorgehen:

1. Anforderungsaufnahme
   1. Der Product Owner nimmt die neue Anforderung auf. (bspw. eines Fachbereichs)
2. User Story
   1. Der Product Owner erstellt die User Story gemäß der o.g. Kriterien
3. Verfeinerung
   1. Gemeinsam mit dem Team werden die User Stories im Backlog Refinement Meeting 
      1. besprochen
      2. mit Akzeptanzkriterien versehen
      3. geschätzt

Beispiel:

• Epic: Als nicht-eingeloggter User möchte ich, mich für einen Newsletter registrieren können, um über aktuelle Firmeninformationen informiert zu werden.
  • User Story 1
    • Als nicht eingeloggter User möchte ich ein E-Mail Adresseingabefeld vorfinden, um mich mit meiner E-Mail-Adresse für den Newsletter eintragen zu können
  • User Story 2
    • Als nicht eingeloggter User möchte ich eine E-Mail Bestätigung (Opt-In) erhalten, sobald ich mich für den Newsletter registriert habe, um SPAM vorzubeugen.
  • User Story 3
    • Als User möchte ich in dem Newsletter die Möglichkeit haben, mich vom Newsletter abzumelden, um somit keinen weiteren Newsletter zu erhalten.