# 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