Dies ist eine alte Version des Dokuments!


User Stories, Definition of Done und Product Backlog


User Stories sind kurze, einfache Beschreibungen einer Funktion aus Sicht der Benutzer:innen. Sie erklären, wer etwas will, was er/sie will und warum. User Stories helfen, die Anforderungen an ein System klar aus Benutzersicht zu formulieren. Sie machen Teams bewusst, für wen eine Funktion entwickelt wird und dienen als Grundlage für Planung, Umsetzung und Tests.

Aufbau einer User Story:

```
Als [Rolle]
möchte ich [Funktionalität],
damit [Nutzen].
```

Beispiel Study Buddy Finder:

```
Als Student:in
möchte ich mein persönliches Lernprofil erstellen,
damit ich meine Fächer, Interessen und Lernzeiten angeben kann.
```

1.2 Schätzung einer User Story

User Stories werden in Story Points geschätzt. Story Points sind eine Maßeinheit zur Einschätzung des Gesamtaufwandes, der für die vollständige Umsetzung einer User Story nötig ist.

Wenn wir etwas mit Story Points einschätzen, geben wir jedem Item eine gewisse Punktzahl. Die blossen Zahlen sind dabei nicht wichtig. Es sind die relativen Werte, um die es geht. Eine Story, die mit 1 Punkt eingeschätzt wird, sollte also halb so groß sein wie eine Story, die mit 2 Punkten eingeschätzt wird. Eine Story mit 3 Punkten sollte daher dreimal so groß sein wie die Story mit 1 Punkt.

Oft wird für die Schätzung auch T-Shirt Grössen eingesetzt: also S, M, L, XL.

1.3 Wenn eine User Story zu groß ist

Eine Story sollte nicht zu groß sein. Wird eine User Story also als XL geschätzt, bietet es sich an, die Story in viele kleinere Stories zu unterteilen. Eine Story, die zu viel Arbeit erfordert, nennt man „Epik“ (Epic User Story).

Beispiel:

  • Epic User Story: „Profilverwaltung für Student:innen implementieren“
  • User Stories:
  1. Lernprofil erstellen
  2. Lernzeiten speichern
  3. Bestätigung nach Speicherung anzeigen

Akzeptanzkriterien sind konkrete Bedingungen, die erfüllt sein müssen, damit die Story als „fertig“ gilt. Sie dienen als Checkliste für Entwickler:innen und Tester:innen. So stellt das Team sicher, dass alle wichtigen Funktionen umgesetzt wurden.

Beispiel Study Buddy Finder:

* Die Benutzerin / der Benutzer kann Name, Klasse, Fächer und Lernpräferenzen eingeben. * Die Benutzerin / der Benutzer kann die verfügbare und bevorzugte Lernzeiten angeben. * Die Daten werden sicher im Benutzerkonto gespeichert. * Nach dem Speichern erhält der Benutzer eine Bestätigungsmeldung.

Was ist das? Die Definition of Done legt fest, wann eine Aufgabe oder Story wirklich fertig ist.

Warum ist sie wichtig?

* Vermeidet Missverständnisse im Team. * Stellt sicher, dass eine Story wirklich nutzbar ist und keine losen Enden hat. * Schafft Transparenz für alle Beteiligten.

Wann ist etwas done?

* Wenn alle Akzeptanzkriterien erfüllt sind. * Wenn zusätzliche Teamregeln der DoD eingehalten wurden, z. B.:

  • Code ist getestet
  • Code ist dokumentiert
  • Funktion ist im System integriert

Wie wird das überprüft?

* Entwickler:innen prüfen, ob die Story funktioniert. * Tester:innen führen Tests anhand der Akzeptanzkriterien durch. * Das Team bestätigt gemeinsam: „Done“.

## 3. Product Backlog

Wohin mit den User Stories? Alle User Stories werden in einem Product Backlog gesammelt.

Was ist der Product Backlog?

* Eine geordnete Liste aller Aufgaben, Features und Ideen für ein Produkt. * Enthält User Stories, Bugs, Verbesserungen oder technische Aufgaben. * Sortierung nach Priorität: Wichtigste Aufgaben oben, unwichtige weiter unten.

Wie arbeite ich damit?

1. Hinzufügen: Neue User Stories oder Aufgaben kommen ins Backlog. 2. Priorisieren: Team entscheidet, welche Aufgaben zuerst umgesetzt werden. 3. Schätzen: Jede Story wird hinsichtlich Aufwand eingeschätzt. 4. Umsetzen: Stories vom Backlog werden in Sprints übernommen.

Beispiel Study Buddy Finder Backlog:

Priorität User Story Status Akzeptanzkriterien
——— ——————– —— ————————————————————————————————————–
Hoch Lernprofil erstellen offen Name, Klasse, Fächer, Lernpräferenzen eingeben; Zeiten speichern; Daten sicher speichern; Bestätigung anzeigen
Mittel Profil bearbeiten offen
Niedrig Profil löschen offen

### Zusammenfassung: Wie alles zusammenhängt

1. User Story → beschreibt, was eine Benutzer:in will 2. Akzeptanzkriterien → zeigen genau, wann die Story erfüllt ist 3. Definition of Done → legt fest, wann die Arbeit wirklich fertig ist 4. Product Backlog → sammelt alle Stories und Aufgaben, priorisiert und organisiert

So entsteht ein klarer, transparenter Ablauf von der Idee bis zur fertigen Funktion.

Wenn du willst, kann ich das Ganze noch in einem übersichtlichen Schaubild darstellen, das die Lernenden sofort verstehen – von User Story bis Done und Backlog. Willst du, dass ich das mache?

  • de/modul/m426_v2025/learningunits/lu01/userstories.1762437058.txt.gz
  • Zuletzt geändert: 2025/11/06 14:50
  • von gjenni