Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-IFP/teams/Team-Infinity-DoR-DoD.md

Team Infinity DoR / DoD

Version: 17 | Last modified: 2024-09-23T10:37:07.872+02:00 Source: confluence page ID 243078773

---

Definition of Ready „Ready is when the team says: ‚Ah, we got it‘“.  Jeff Sutherland

DoRDie Definition of Ready hilft beim Verständnis des Development-Teams darüber, was als Ergebnis zu liefern ist. Anhand dieses Verständnisses beantwortet das Development-Team die Frage, ob es das Ergebnis liefern kann. Ein Product Backlog ist "Ready", wenn es genügend Product Backlog Items an der Spitze hat, die diesen Kriterien entsprechen.

INVESTIndependent and immediately actionably – Product Backlog Items sind im Sprint unabhängig voneinander, damit sie umpriorisiert werden und besser geschätzt werden können. Zudem wird unnötiger Planungsaufwand für ihre Umsetzung vermieden. Alle Voraussetzungen sind vor Sprintbeginn aufgelöst. Die Umsetzer geben das Feedback, dass sie beginnen können. Negotiable – PBIs* sind verhandelbar, damit die Details im Gespräch festgelegt werden und damit bessere oder günstigere Varianten identifiziert werden. Valuable – PBIs bringen dem Kunden einen Mehrwert, damit nur Anforderungen umgesetzt werden, die Wert schöpfen und damit nur das umgesetzt wird, was gebraucht wird. Backlogeinträge, die nicht fertig sind, liefern keinen Wert. Estimable – PBIs sind schätzbar. So wird erkannt, ob die Umsetzer den Backlog Item fachlich und technisch verstehen. Small – PBIs haben die richtige Größe, damit sie in einer Iteration umgesetzt werden können. Testable – PBIs sind testbar durch den Kunden. Sie haben Akzeptanzkriterien. *PBI = Product Backlog Item (User Story)

Nummer | DoR-Kriterien (Enabler + Story) | 1 | ID, Titel, Beschreibung (Empfehlung zur Beschreibung inkl. „Als möchte , um “) sind vorhanden. | 2 | Klare und messbare / prüfbare Akzeptanzkriterien (ggf. auch im Sinne einer (Scope-) Abgrenzung beschreiben was die Story nicht können muss) sind definiert / beschrieben. Es muss definiert sein wer Enabler abnimmt, falls eine Abnahme erforderlich ist.   | 3 | Story / Enabler wurde vom Team verstanden und ist in Story Points geschätzt. | 4 | Story / Enabler sind möglichst in einer Iteration (Sprint) umsetzbar. | 5 | Logiken der funktionalen Anforderungen einer Story sind ausformuliert oder per Link referenziert, wenn vorhanden. | 6 | Story- / Enabler-spezifische nichtfunktionale Anforderungen (NfA) sind definiert / beschrieben / verlinkt oder nicht notwendig. | 7 | Story / Enabler ist (wenn möglich und sinnvoll)  einem Feature und einem Objective zugeordnet.  | 8

| Ggf. vorhandene Abhängigkeiten zu anderen Enablern, Features bzw. Stories sind falls nötig beschrieben und sofern möglich referenziert.  | 9 | Offene Punkte zu Story / Enabler sind geklärt (vermerkt in Story / Enabler).  | 10 | Folgendes wurde bei Durchsprache der Story / des Enablers geklärt: Wer sind die Ansprechpartner? Welche Rollen werden zur Umsetzung benötigt (BE, Dev, Test)? |

Definition of Done

DoDUm ein gemeinsames Verständnis herzustellen, vereinbaren die Mitglieder des Entwicklungsteams und der Product Owner eine sog. Definition of Done (kurz DoD). Die DoD zeigt, was alles zu tun ist, damit künftige Anwender die neue Funktionalität auch nutzen können. Backlogeinträge, die die DoD nicht erfüllen, kommen zurück ins Product Backlog und der Product Owner entscheidet über die weitere Umsetzung.

Minimal DoD Code fertig Code getestet (keine bekannten Fehler) Doku fertig Abgenommen durch den Product Owner Bereit für die Übernahme in die Produktivumgebung

Nummer | DoD-Kriterien (Enabler + Story) | 1 | Die Akzeptanzkriterien sind erfüllt. | 2 | Neue Tests wurden geschrieben oder vorhandene erweitert/angepasst.  Ziel: Code-Coverage im Backend von mindestens 80% | 3 | Durchzuführende Tests laut Testkonzept (manuelle und automatische) sind erfolgreich und dokumentiert. GUI-Test (zu definieren in Testtermin; Vorschlag: manueller Test im aktiven Sprint, automatisiert im Folgesprint) | 4 | Der Code wurde qualitätsgeprüft (z.B. Peer Review, Clean Code, Kommentare, statische Prüfung). | 5 | Der Code ist versioniert, freigegeben und erfolgreich in den Master gemergt. | 6 | IT-Security-Vorgaben wurden berücksichtigt (wenn vorhanden und bekannt). | 7 | Die Story-spezifische technische Beschreibung/Dokumentation ist erstellt oder wurde als Folgestory im Backlog erfasst. | 8 | Die Story-spezifische fachliche Beschreibung/Dokumentation ist erstellt oder wurde als Folgestory im Backlog erfasst. | 9 | Die Releasenotes wurden Story-spezifisch angepasst/erweitert. |