Orchestrator/bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/Team-Rogue-One.md

# Team Rogue One

Version: 16 | Last modified: 2026-05-06T13:22:22.709+02:00
Source: confluence page ID 533429844

---

Termine:
 | Montag | Dienstag | Mittwoch | Donnerstag | Freitag | 
09:15 | 
 | Daily | Daily | Daily | Daily | 
09:30 | Status Meeting  | 
 | 
 | 
 | 
 | 
13:00 | 
 | Refinement | 
 | Teammeeting | 
 | 
15:00 | 
 | Retro | 
 | 
 | 
 | 

Teammitglieder:Sebastian.Goendoer@deutschebahn.com (PO)
Uenal.Dogdu@deutschebahn.com (SM)
martin.stieglitz@deutschebahn.com (FO)
Dirk.Di.Wagner@deutschebahn.com (DEV)
Stefan.St.Werner-extern@deutschebahn.com (DEV)
Jonas.Monecke-extern@deutschebahn.com (DEV)
Lukas.Schmiedgen-extern@deutschebahn.com (DEV)
Fred.Fluegge-extern@deutschebahn.com (DEV)

DoR - Definition of Ready für Feature und Enabler Owner des Feature/Enabler ist bestimmt (Hinweis: Feld Bearbeiter/Assignee des Feature/Enabler in ariJa)
 Feature/Enabler ist einer Capability zugeordnet
 Risiken sind dokumentiert und mögliche Maßnahmen definiert
 Abhängigkeiten sind, soweit bekannt, beschrieben und innerhalb von ariJa verlinkt (ART interne). Externe Abhängigkeiten sind im Feature/Enabler dokumentiert und abgestimmt.
 Relevante Dokumente sind verlinkt oder angehängt
 Das Feature/Enabler wurde allen Teams vorgestellt, besprochen und von allen verstanden
 Feature/Enabler ist innerhalb eines PIs umsetzbar und möglichst unabhängig zu anderen Feature
 Die Bewertungen zur WSJF Berechnung (Business Value, Time Criticality, RROE) sind eingetragen
 Feature ist in T-Shirt Sizes geschätzt
 NEU: Testing ist berücksichtigt.
DoD - Definition of Done (User Stories, Bugs, Enabler)(Stand: April 2025)
Akzeptanzkriterien sind erfüllt: die Entwicklung deckt die Akzeptanzkriterien vollständig ab. Falls diese nicht aktuell sein sollten, ist eine Anpassung in Absprache mit dem Ticketersteller erfolgt.
Reviewer-Approval: der Code wurde gereviewed, einschließlich der Einhaltung von SonarQube-Grenzen, Unit Tests, Sicherheits-Scans und Conventional Commits. Bei Liquibase-Skripten ist ein zusätzliches Review durch Björn oder bei Abwesenheit durch Christian/Adrian erfolgt.
Tester-Approval: die Regressionstests wurden überprüft und angepasst, progressive Tests auf der EU sind erfolgreich und die Testdurchführung ist dokumentiert.
Code-Merge: Codeänderungen sind in den Zielbranch (Master- oder Featurebranch für Release Bundles) gemerged.
Nachtest auf TU: bei Bedarf wurde ein Nachtest auf der Testumgebung durchgeführt.
Releaseinformationen: Die Lösungsversion im Jira-Ticket und die Deployment-Anmerkungen in Confluence sind gepflegt.
Die Storie wurde vom PO bzw FO abgenommen

Abstimmung hinsichtlich zukünftiger Tests:                
Testdriven Development → Bereits im Refinement soll darauf geachtet werden was später getestet werden soll. Teile des Testdesigns würden sich daraus bilden lassen.
Unit Tests werden von den Entwicklern durchgeführt.
manuelle Tests sollen von jemandem vorgenommen werden, der an der Entwicklung der Story nicht beteiligt
Bereits bei der Erstellung der Story werden KI generierte Testszenarien aufgezeigt
fehlende xray Skills sollen aufgebaut werden → Schulung oä
Abstimmung zur zukünftigen Releaseplanung            Releasetermine werden im Refinement in´s Ticket geschrieben
Stories dürfen nur dann gemerged werden, wenn sie bis zum Release noch getestet werden können
Die Kommunikation was released wird, kommuniziert der PO im ART Sync
...
Abstimmung zur Nutzung des KANBAN Boards          Erstellung von Tickets & PriorisierungGrundsätzlich ist der Feature Owner für das Schreiben der Tickets zuständig. Es kann jedoch jedes Teammitglied Tickets erstellen
Die Nummerierung der Features entspricht der aktuellen Priorität. Bei Bedarf werden auch Stories nummeriert
Grundsätzlich stellt  die Reihenfolge der Tickets die Priorität dar
die Priorität wird auch im Ticket selbst hinterlegt. S.h. Abbildung unten

Hierarchie im BoardEbene 1: Feature
Ebene 2: Story, Enabler, Bug
Ebene3: Aufgabe

Aktuelle Lanes im KANBAN BoardBlocked | Open | Fachlich geklärt | In Progress | Ready4Test | In Test | Ready4TU | Ready4AU | 
enthält alle Tickets, die bereits "In Progress" waren und aktuell nicht weiter bearbeitet werden können. | Stellt das Sammelbecken für alle Tickets dar. | Als fachlich geklärt gilt ein Ticket wenn es folgende Eigenschaften erfüllt:
erfüllt die DoR Kriterien 
Akzeptanzkriterien sind vollständig
enthällt eine Beschreibung
Refinement hat stattgefunden
enthält Testszenarien
 | alle Tickets in Bearbeitung
als Richtlinie gilt: WIP-Limit = 3
 | Akzeptanzkriterien sind erfüllt
 | Tests am Laufen
 | Tests waren erfolgreich, Bugs wurden behoben
fachliche Bewertung ist erfolgt
 | alle bisherigen Tests waren erfolgreich
das Ticket ist fertigentwickelt (done)
 | 

Offene Todos:

4
c53c64d8-4a8a-4a70-a57c-c01a5b741410
incomplete
Erstellung eines Templates für eine Checkliste

5
d047a4a8-29ae-42c6-812c-cbf7ee820379
complete
Kommunizieren, dass das Team sein Commitment aus dem letzten PI nicht wird halten können.

6
b165b729-cfb5-44e4-9d56-481c5aab018e
incomplete
 

Der Refinement Prozess   
Verantwortlichkeiten
Product Owner / Feature Owner
Wählt Stories aus dem Backlog für das Refinement aus. Bis spätestens zum Statusmeeting.
Stellt sicher, dass jedes Ticket die Definition of Ready (DoR) erfüllt
Team
Sichtet die Tickets vor dem Refinement
Notiert offene Fragen und Unklarheiten
Gibt eine Aufwandsschätzung ab in der sowohl Aufwand als auch Komplexität berücksichtigt werden

Ablauf
PO/FO wählt relevante Stories aus dem Backlog
PO/FO priorisiert die Tickets (Top-Ticket ganz oben)
PO/F prüft die Definition of Ready
→ nicht erfüllt: Ticket nachschärfen
Team bereitet sich vor und sammelt Fragen
Refinement-Meeting:
Akzeptanzkriterien werden geprüft
Testszenarien werden ergänzt

Ergebnis des Refinements
✔ Klar verstandene Tickets
✔ Vollständige Akzeptanzkriterien
✔ Ergänzte Testszenarien
✔ Gute Basis für verlässliche Schätzungen