﻿# 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 <Rolle> mÃ¶chte <Funktion>,Â um <Zweck>â)Â 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. |
