# 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
