alablz
commented
3 years ago Hallo zusammen, ich würde jetzt schonmal anfangen die user Stories aufzuschreiben die mir eingefallen sind und dann können wir ja gemeinsam die vorschlage besprechen und gegebenenfalls nochmal bearbeiten :)
Das ist ein allgemeines Beispiel, um zu sehen, wie die User Stories als Issue zu implementieren sind. Für Änderungsanmerkungen bitte die Kommentarsektion unterhalb nutzen!
ZIEL: Jede/r sollte so viele User Stories wie möglich erstellen. 20 abgeschlossene User Stories sind Voraussetzung für Iteration 1.
Hinweise zur Form der User Stories:
Der Titel sollte die folgenden Form haben: Als [Rolle] möchte ich [Funktion] um [Nutzen]
Jede User Story soll in ihrer Beschreibung eine Liste mit Akzeptanzkriterien enthalten, die über die gemeinsame Diskussion erarbeitet werden sollen. Diese Kriterien müssen verständliche Aussagen mit klarem pass/fail Resultat sein, eine funktionale oder nicht-funktionale Anforderung spezifizieren und das Ziel beschreiben (nicht die Lösung). Sind alle Akzeptanzkriterien erfüllt, gilt die User Story als abgeschlossen.
AKZEPTANZKRITERIEN
[ ] Kriterium 1
[ ] Kriterium 2
[ ] Kriterium 3
LABELS: Jede User Story wird mit dem Label "User Story" markiert. Das Label "in Arbeit" zeigt, dass die User Story noch in Arbeit ist. Das Laben "Abgeschlossen" zeigt, dass die User Story fertig ist.
DISKUSSION: Die Diskussion zu einzelnen User Stories findet in der Kommentarsektion unterhalb der jeweiligen Beschreibung statt (siehe unten).
ALLGEMEINES:
Erläuterung der genannten Begriffe: • Rolle: Wer fordert etwas an? Der Anforderer ist meist der spätere Nutzer des Systems oder der Nutznießer der zu entwickelnden Lösung. • Funktion: Was wünscht sich der Anforderer? Der Anforderer wünscht sich, dass etwas bestimmtes passiert. Je klarer und präziser der Wunsch in die User Story eingeht, desto hilfreicher ist die User Story für das Entwicklerteam, um die Anforderungen zu realisieren. • Nutzen: Warum ist das für den Geschäftsfall wichtig? Durch die Anforderung soll ein Ziel erreicht werden. Der Anforderer verspricht sich davon einen Nutzen. Die Beschreibung des Grundes der Anforderung liefert dem Entwicklerteam weitere Informationen zur richtigen Ausführung.
Eine Hilfestellung bei der Formulierung von User Stories sind die sogenannten INVEST Kriterien, die gute User Stories erfüllen sollen:
Independent (unabhängig): Jede einzelne Geschichte sollte unabhängig von anderen User Stories sein. Die Umsetzung einer Story darf nicht voraussetzen, dass vorher eine andere Story umgesetzt wurde. Negotiable (verhandelbar): User Stories sind keine unumstößlichen Vertragstexte. Product Owner, Stakeholder und das Entwicklerteam diskutieren und präzisieren die User Stories gemeinsam, um ein optimales Verständnis zu erzielen. (Dieser Punkt hat im Kontext der Vorlesung vermutlich weniger Auswirkungen auf Ihre Arbeit.) Valuable (nützlich): Das Ergebnis der Story muss für den Anwender sinnvoll sein und Wert stiften. Estimable (schätzbar): Das Entwickerteam muss in der Lage sein, Aufwände für die Realisierung abschätzen zu können. Small (klein): Der Umfang der User Story sollte angemessen sein, das heißt, sie sollte in einem Sprint realisierbar sein. Testable (testbar): Jede User Story muss getestet werden können. Mit dem Test wird die erfolgreiche Umsetzung der User Story festgestellt.