Orchestrator/bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Story-Template-Team-OnePiece.md

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