# Team Rules

Version: 11 | Last modified: 2026-05-21T00:57:52.845+02:00
Source: confluence page ID 318903955

---

Neben unseren Vereinbarungen wir der DoD&DoR oder unserem Ticket-Workflow entstehen sukzessive im Rahmen unserer Retroa oder anderen Workshops Regeln fÃ¼r unser Team, die wir auf dieser Seite dokumentieren.Â 

Thema | Nr. | Regel | 
Â 
Â 
Â 
Â 
Â 
Â 
Board, Workflow & Tickethandling
Â 
Â 
Â 
 | 1
 | Wir verwenden das Scrum Board, um unsere Arbeit und Fortschritte, die auf das Sprintziel einzahlen, fÃ¼r alle sichtbar zu machen.
 | 
2
 | Sobald eine Person ein Ticket aus dem Sprint Backlog zieht, trÃ¤gt sie bis zur Fertigstellung die Hauptverantwortung dafÃ¼r.
 | 
3
 | Falls ein Ticket blockiert ist, sprechen wir dies proaktiv im Daily an und hinterlassen einen Kommentar am Ticket, um den Grund fÃ¼r die Blockade zu dokumentieren.
 | 
4
 | Sollte ein Ticket innerhalb eines Sprints nicht abgeschlossen werden kÃ¶nnen, benennen wir die GrÃ¼nde dafÃ¼r proaktiv im Daily.
 | 
5
 | Wir arbeiten nach dem Prinzip "Stop starting, Start finishing"
 | 
6
 | Es sind sich alle einige im Team, dass sich Anforderungen/AKs wÃ¤hrend des Sprints durch externen Einfluss verÃ¤ndern kÃ¶nnen.
Falls diese Fall eintritt, prÃ¼fen wir als Team, ob das Sprint Commitment dadurch beeinflusst wird. Wenn ja, wird ein Folgeticket fÃ¼r den nÃ¤chsten Sprint erstellt oder gleichwertiges Ticket aus dem Sprint entfernt, um den Sprint Scope konstant zu halen.
Sollten sich Anforderungen/AKs verÃ¤ndern, werden diese immer am Ticket in Jira festgehalten.
 | 
7
 | Nach Fertigstellung eines Tickets (Ticket ist in "In Review") gibt die Entwickler*in per Jira Kommentar eine EinschÃ¤tzung ab, ob die SchÃ¤tzung valide war.
 | 
8
 | Wir streben als Team eine hochwertige StoryqualitÃ¤t an, damit diese effizient und effektiv abgearbeitet werden kann.
 | 
9
 | Wir beginnen die Umsetzung von Anforderungen (Features, Enabler, User Stories) erst, wenn ihr Nutzen fÃ¼r die Benutzer:innen und das GeschÃ¤ft klar und nachvollziehbar ist.
 | 
10
 | Sobald ein ART-Feature den Status "Ready" im Rahmen des ART-Feature-Refinement erhÃ¤lt, wird dieses im Team-Refinement vom PO oder BE vorgestellt.
 | 
11
 | Bis eine hÃ¶here Entwicklungsumgebung verfÃ¼gbar ist fÃ¼r deployment der Anwendung, wird mit dem DoD Punkt 5, "hÃ¶chstmÃ¶gliche Umgebung", die INT-NEXT, gemeint.
 | 
Â 
Â 
Â 
Â 
Â 
Meetings & Dokus
 | 12
 | Wir sagen Termine zu oder ab. 
 | 
13
 | Bei der Festlegung von Terminen beschreiben wir klar das Ziel und geben Anweisungen zur Vorbereitung fÃ¼r die Teilnehmenden.
 | 
14
 | Wir bereiten uns entsprechend den Zielen und der Agenda eines Termins vor.
 | 
15
 | Die anwesenden Personen haben die Befugnis, Entscheidungen zu treffen, auch wenn nicht alle Mitglieder des Teams anwesend sind.
 | 
16
 | Bei Abwesenheiten wird eine Vertretung fÃ¼r wichtige Meetings organisiert.
 | 
17
 | Wir dokumentieren Ergebnisse, die fÃ¼r das gesamte Team relevant sind. 
 | 
18
 | Der Single Point of Truth fÃ¼r fachliche Dokumentationen ist Confluence.
 | 
19
 | Der Single Point of Truth fÃ¼r technische Dokumentationen ist GitLab.
 | 
20
 | Vor Abwesenheiten (1 Tag oder mehr) informieren wir das Team im Daily und im Chat. 
 | 
21
 | Nach einer Abwesenheit informieren wir uns proaktiv Ã¼ber das Geschehene (Holschuld).
 | 
22
 | Vor Abwesenheiten stellen wir sicher, dass wegen meiner Abwesenheit keine Arbeiten im Rahmen des Sprints blockiert werden. 
 | 
Â 

Kommunikation & Kultur

Â 
 | 23
 | Wir kommunizieren proaktiv an welchen Aufgaben wir arbeiten.
 | 
24
 | Jedes Teammitglied fÃ¼hlt sich fÃ¼r das Produkt verantwortlich.
 | 
25
 | Es wird im Team offen und ehrlich Feedback gegeben.
 | 
26 | Bei Konflikten werden diese direkt und wertschÃ¤tzend kommuniziert.
 | 
27 | Bei wichtigen Entscheidungen (z.B. VerÃ¤nderung der Teamstruktur) mÃ¼ssen alle Mitglieder die MÃ¶glichkeit haben abstimmen zu kÃ¶nnen. Das jeweilige Vorgehen wird individuell im Team abgestimmt.
 |
