# Story Template - Team OnePiece

Version: 3 | Last modified: 2025-09-05T10:38:01.964+02:00
Source: confluence page ID 485040169

---

TitelAPN (Komponente): TitelÂ 
Titel: Was gemacht wird -> Ã¤hnlich zu Git-Commits (Imperativ)

AkzeptanzkriterienDie Akzeptanzkriterien sollen einen bestimmten Zustand oder ein bestimmtes Verhalten der Komponente beschrieben. Im idealen Fall ist jedes einzelne AK unabhÃ¤ngig voneinander testbar und erfÃ¼llbar.
Akzeptanzkriterien sollten mÃ¶glichst in Gherkin-Schreibweise als testbares Szenario beschrieben sein. Die Formulierung sollte immer im positiv geschrieben sein, selbst bei einem Szenario mit negativem Ausgang. Das hat gleich mehrere Vorteile:
Bessere VerstÃ¤ndlichkeit
Positive Aussagen sind fÃ¼r Fachbereiche und Nicht-Entwickler leichter zu lesen.

Beispiel:
Negativ: Then the user is not logged in

Positiv: Then the user stays on the login page
â Die zweite Variante beschreibt klarer, was tatsÃ¤chlich passiert.

Eindeutigkeit
Negative Formulierungen fÃ¼hren oft zu Interpretationsspielraum (ânicht eingeloggtâ â heiÃt das: Fehlermeldung? ZurÃ¼ck zur Loginseite? Einfach nichts passiert?).

Positive Formulierungen beschreiben ein beobachtbares Ergebnis.

Bessere Testautomatisierung
Tests lassen sich einfacher prÃ¼fen, wenn ein klarer Zustand Ã¼berprÃ¼ft wird.

Positiv: Then I see an error message "Invalid credentials"

Negativ: Then I do not see the dashboard
â Beim negativen Test kÃ¶nnte der Test "bestehen", auch wenn etwas vÃ¶llig anderes angezeigt wird (z. B. eine leere Seite).

Weniger kognitive Belastung
Menschen mÃ¼ssen bei Negationen Ã¶fter gedanklich âum die Ecke denkenâ.

Positiv formulierte Szenarien sind intuitiver nachzuvollziehen.

Eine Schablone dafÃ¼r wÃ¤re:
Scenario:Â Komponente XYZ macht etwas
Given ein bestimmter InputÂ 
Given eine mÃ¶gliche Bedingung
When eine bestimmte Aktion oder Situation geschieht
Then wird ein bestimmtes Verhalten beobachtet
Then ist eine bestimmtes Ergebnis eingetreten

Es sollte immer mindestens ein Positiv- und ein Negativ-Beispiel vorhanden sein.

DetailbeschreibungZu klÃ¤rende Fragen:
Was soll in der Story geschehen?
Welche Vorbedingung soll erfÃ¼llt sein?
Was ist der Nutzen, den diese Story kreiert?

Fachliche BeschreibungFachliche Einordung der Anforderung in den Business Kontext
Gerne auch eine grafische Ãbersicht mit Figma:

Technische InformationenFÃ¼r die Umsetzung hilfreiche Informationen, Links etc.
SST-Beschreibung

Beispiel-Datenset
AusblickGibt es Auswirkungen auf andere Komponenten?

Out-of-ScopeWas soll nicht getan werden?

NFAVerfÃ¼gbarkeit?
Umgang mit Daten?
Monitoring?
Skalierbarkeit?
ReminderDefinition of Ready:Vor Refinement von PO/BA's zu klÃ¤ren:* Die USER-Story ist ins Gesamtprojekt eingeordnet ("Als ... mÃ¶chte ich, dass..., WEIL..."). Motivation wird erklÃ¤rt und These Ã¼ber Nutzen der Story aufgestellt.
* Akzeptanzkriterien sind formuliert (wÃ¼nschenswert: konkretes BDD given/when/then, Example-Mapping)
* Zusammenstellung verfÃ¼gbarer fachlicher Dokumentation (verlinkt oder direkt in der Story)
* VerfÃ¼gbarkeit der Testdaten ist geklÃ¤rt
* AbhÃ¤ngigkeiten zu anderen Teams im Projekt oder extern sind geklÃ¤rt
* Story kann nicht fachlich sinnvoll kleiner geschnitten werden

Vor SchÃ¤tzung einer Story von den Entwicklern zu klÃ¤ren* Identifikation der betroffenen (Software)-Komponenten (intern und extern)
* Aktueller Zustand der betroffenen Software-Komponenten
* Testbarkeit ist abgeklÃ¤rt
* Notwendige Zugangsdaten/Tools sind bekannt
* AbhÃ¤ngigkeiten zu anderen Stories oder Teams
* VerfÃ¼gbare technische Dokumentation ist bekannt
* Story kann nicht technisch sinnvoll kleiner geschnitten werden
