User Story

Alle Features werden in Form von User Stories beschrieben

As a {role} i want {function} because {benefit}

Acceptance criterias:

  • ac 1
  • ac 2
  • ac 3

Die User Story beschreibt den Zustand und das Verhalten des Inkrements nach Umsetzung der Anforderungen und keinen (technischen) Lösungsweg (außer technische Rahmenbedingungen)

INVEST Kriterien

Independent – unabhängig. Die Stories sollten unabhängig voneinander implementierbar sein.

Negotiable – verhandelbar. Änderungen an der Story können (in Absprache) vorgenommen werden.

Valuable – nützlich. Die Umsetzung der Story erhöht den Gebrauchswert des Produkts für den Endkunden.

Estimable – quantifizierbar. Der Aufwand für die Umsetzung muss abschätzbar sein. (Alle notwendigen Informationen müssen dafür vorhanden sein)

Small – klein. Der Aufwand für die Umsetzung sollte überschaubar sein. Innerhalb eines Sprints umsetzbar.

Testable – überprüfbar. Die erfolgreiche Umsetzung der Story sollte sich anhand Kriterien überprüfen lassen. Sinnvoll messbare Akzeptanzkriterien

Story Beispiel

Onboarding, Login and User- management

DSGVO

As a user I want to register into the app, so that I am able to book machines and can use the service

Acceptance criterias:

  • when showing the login screen, there is an option to register as a new user
  • if the user presses the register button, the registration process starts
  • The user will go through an onboarding process step by step, the user can only go to the next step, when he fulfill all requirements of the current step
    • Step 1 – The user has to enter his email address and a password (2 times for validation) for the initial registration.
      • Exception E-Mail already exists -> show message to user
      • Exception Password rules are not fulfilled -> show message to user
    • Step 2 – after that, an email is send to the user with a 4 digit code for email validation (confirmation code should be part of the email subject). The user can enter the 4 digit code to validate his email. there is also an option to resend the email
      • Exception Digit Code is wrong -> show message to user
    • Step 3 – The user has to enter his address data (street, number, postal code, city) all fields are mandatory
      • Exception Mandatory fields -> next step ist only possible, when all mandatory fields are filled
    • Step 4 – The user has to upload a photo of his id document (id card, driving license or passport) After taking a photo, the user has the option to redo or confirm it. Show upload progress after taking the photo
      • Exception upload failed -> show message, user can initialize reupload
  • after the user gone through all steps an overview screen is shown where he can finally confirm
  • on the confirmation screen there are checkboxes for data policy and product information consents
  • when a user aborts after the second step of the registration the questionnaire will always start direct after login
  • the layout and interactions should be implemented according to the design and the common usage and interactions pattern of the respective mobile platform

Tipps zum User Story Schreiben

  • Halte die Story so simpel wie möglich
  • Beschreibe in der Story klar den erwarteten Ablauf und die definierten Zustände
  • Fokussiere nicht nur auf den “Happy Path” und versuche auch die Ausnahmen zu definieren
  • Ergänze die Story um alle Informationen die im direkten Zusammenhang mit der Umsetzung stehen
  • Eine User Story ist kein fester Vertrag – halte die Kommunikation mit dem Team offen um den besten Weg der Umsetzung gemeinsam mit dem Team zu definieren .

Story Estimation bei Elasticbrains

Bewertung der USER STORY nach

  • Komplexität
  • Risiko
  • Abhängigkeiten

Schätzung im Planning Poker

  • Jeder Entwickler*in schätzt die User Story für sich
  • Alle zeigen gleichzeitig Ihre Schätzung
  • Die Entwickler*innen mit der höchsten und niedrigsten Schätzung erklären ihre Standpunkte
  • Das Team diskutiert und einigt sich auf einen Wert
  • Die/der Entwickler*in mit der höheren Schätzung kann auf die Schätzung im Zweifelsfall bestehen und dann wird diese genommen
  • ggfls. kann die/der Product Owner*in die Story verändern um die Komplexität, Risiko oder Abhängigkeiten zu reduzieren

Storypoints bei Elasticbrains -> Fibonacci ohne 2

Scrum Storypoints Fibonacci

bei einer Schätzung über 13 Storypoints muss die Story gesplittet werden