Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:modul:m426_v2025:learningunits:lu01:userstories [2025/11/06 14:28] – gjenni
+++ de:modul:m426_v2025:learningunits:lu01:userstories [2025/11/06 15:12] (aktuell) – gjenni
@@ Zeile 1: / Zeile 1: @@
-Eine Story bzw. User Story ist ein kurzes, nicht-technisches Statement einer Softwaresystem-Anforderung, formuliert aus Sicht des Endnutzers. Eine User Story wird meist nach folgendem Muster geschrieben:
+====== User Stories, Definition of Done und Product Backlog ======
-"Als ❮NutzerIn❯ möchte ich ❮Aktion❯, damit ❮Ziel❯."
+===== 1. User Stories =====
+==== 1.1 Was sind User Stories? ====
+\\
+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.\\
+```
-Beispiel:\\
-**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:
+. Lernprofil erstellen
+. Lernzeiten speichern
+. Bestätigung nach Speicherung anzeigen
+----
+==== 1.4 Akzeptanzkriterien ====
+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. Bei der Formulierung der Akzeptanzkriterien ist es wichtig, auch die Stakeholder miteinzubeziehen. Es muss für alle Beteiligten klar sein, was mit der Story genau entwickelt werden soll.
+**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.
+Wenn Teams diese Kriterien frühzeitig formulieren und im Product Backlog Refinement weiter ausarbeiten, können sie Missverständnisse früh erkennen und beheben, bevor die Entwicklung startet.
+Gut formulierte Akzeptanzkriterien folgen dem SMART-Prinzip:
+  * **Spezifisch**: beschreibt klar das erwartete Verhalten
+  * **Messbar**: das Ergebnis kann überprüft werden
+  * **Erreichbar** (Achievable): das Team kann es umsetzen
+  * **Relevant**: deckt das Nutzerbedürfnis direkt ab
+  * **Zeitgebunden** (Time bound): definiert bei Bedarf eine zeitliche Erwartung\\
+👉🏽 Schauen Sie sich das Video zur Erläuterung an:[[youtube.com/watch?v=xE2N5SDpN18&embeds_referring_euri=https%3A%2F%2Fwww.agile-academy.com%2F&source_ve_path=OTY3MTQ
+]]
+----
+=====3. Product Backlog =====
+Alle User Stories werden in einem **Product Backlog** gesammelt. Man nennt sie dann auch Product Backlog Item (PBI).
+----
+==== 3.1 Was ist der Product Backlog?====
+Der Product Backlog ist eine geordnete Liste aller Tasks, Features und Ideen für ein Produkt. Er enthält **User Stories**, Bugs und Verbesserungen.
+Sortiert wird nach **Priorität**: Wichtigste Aufgaben oben, unwichtige weiter unten.
+----
+==== 3.2 Wie arbeite ich damit? ====
+. **Hinzufügen:** Neue User Stories oder Aufgaben kommen ins Backlog.
+. **Priorisieren:** Team entscheidet, welche Aufgaben zuerst umgesetzt werden.
+. **Schätzen:** Jede Story wird hinsichtlich Aufwand eingeschätzt.
+. **Umsetzen:** Stories vom Backlog werden in Sprints übernommen.
+Das alles ist Aufgabe des Product Owners.
+**Beispiel Study Buddy Finder Backlog:**
+| Priorität | User Story           | Story Points | Status | Akzeptanzkriterien                                                                                             |
+| Hoch      | Lernprofil erstellen | M | offen  | Name, Klasse, Fächer, Lernpräferenzen eingeben; Zeiten speichern; Daten sicher speichern; Bestätigung anzeigen |
+| Mittel    | Profil bearbeiten    | S| offen  | ...                                                                                                            |
+| Niedrig   | Profil löschen       | XS |offen  | ...                                                                                                            |
+----
+===== 3. Definition of Done (DoD) =====
+Die **Definition of Done** legt fest, **wann eine Aufgabe oder Story wirklich fertig ist**.
+Eine Story ist erst dann wirklich fertig, wenn alle Akzeptanzkriterien erfüllt sind und zusätzliche Regeln, die das Team aufstellt, eingehalten wurden, z.B.:
+  * Code ist getestet (teamintern und auch extern mit KundInnen)
+  * Code ist dokumentiert
+  * Funktion ist im System integriert
+Entwickler:innen prüfen, ob die Story funktioniert. Tester:innen führen Tests anhand der Akzeptanzkriterien durch. Das Team bestätigt gemeinsam: „Done“.
+👉🏽 Schauen Sie sich das Video zur Erläuterung an:[[youtube.com/watch?time_continue=255&v=SAUXt22HRhk&embeds_referring_euri=https%3A%2F%2Fwww.agile-academy.com%2F&source_ve_path=Mjg2NjY]]
+----
+===== 4. Burndown Chart =====
+In einem Burndown Chart werden alle anstehenden Aufgaben dargestellt. Die vertikale Achse repräsentiert das Backlog und die horizontale Achse gibt die Zeit an. Die noch zu erledigenden Arbeiten können durch Story Points oder andere Metriken dargestellt werden. Ein Burndown Chart wird von agilen Teams genutzt, um die gesamte noch zu erledigende Arbeit eines Projekts zu überwachen und vorhersagen zu können, wann alle Arbeiten abgeschlossen sein werden.
+{{ :de:modul:m426_v2025:learningunits:lu01:burndownchart.webp |}}
+Vorteile des Burndown Charts:
+  * Das Team wird gewarnt, wenn etwas nicht nach Plan läuft.
+  * Der Fortschritt wird kommuniziert und man kann abschätzen, wann die Arbeiten erledigt sein werden
+===== 5. Zusammenfassung: Wie alles zusammenhängt =====
+. **User Story** beschreibt, was eine Benutzer:in will
+. **Akzeptanzkriterien** zeigen genau, wann die Story erfüllt ist
+. **Product Backlog** sammelt alle Stories und Aufgaben, priorisiert und organisiert
+. **Definition of Done** legt fest, wann die Arbeit wirklich fertig ist
+So entsteht ein klarer, transparenter Ablauf von der Idee bis zur fertigen Funktion.
-====== Nutzung von User Story:======
-Im Sprint Planning Meeting priorisiert der Product Owner die Stories, die in den Sprint übernommen werden sollen. Das Team gibt jeder Story eine gewisse Menge an Story Points, um den Arbeitsaufwand für diese Story einzuschätzen, und bricht die Stories dann in kleine Tasks herunter, die im Sprint umgesetzt werden. Wenn die Iteration vorbei ist, sollte das Team ein funktionsfähiges Produkt oder Ergebnis entwickelt haben, das den ursprünglichen Anforderungen in der jeweiligen User Story entspricht.
+----  [[https://creativecommons.org/licenses/by-nc-sa/4.0/|{{https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png}}]] (c) Gaby Jenni
+Quelle: https://www.agile-academy.com/de/product-owner/was-sind-story-points/; https://www.agile-academy.com/de/agiles-lexikon/definition-of-done/; https://www.agile-academy.com/de/agiles-lexikon/product-backlog-item-pbi/