Dimensionen und Ebenen der Definition-of-Ready and Done

Donnerstag, 3. Januar 2019
Dieser Blogartikel diskutiert die verschiedenen möglichen und notwendigen Dimensionen und Ebenen der Definition of Ready und Definition of Done.

Dieser Blogartikel diskutiert die verschiedenen möglichen und notwendigen Dimensionen und deren Ebenen der Definition of Ready (DoR) und Definition of Done (DoD). Auf der einen Seite die zeitliche Dimension von einer Anforderung über einen Sprint bis hin zur Release-Ebene und auf der anderen Seite die inhaltliche Dimension einzelner Teams, ganzer Projekte/Produkte bis hin zu einem Programm.

Zeitliche Dimension – Anforderungs-, Sprint-, Release-Ebene: Die Grundidee beider Definitionen ist die Ebene der einzelnen Anforderungen, im Agilen Umfeld meist als User Stories, und beschreibt was bzw. welche Aktivitäten mit diesen vor (DoR) oder in einem Sprint (DoD) passieren soll.

Die häufig damit verwechselte Sprint-Ebene bei der DoD ist demnach in den meisten Fällen überflüssig, speziell wenn die Anforderungs-Ebene klar definiert ist, da der Kern der Sprint-Ebene die Erfüllung der DoD aller einzelnen Anforderungen bzw. Stories ist. In seltenen Fällen macht es jedoch Sinn diese noch um organisatorische Elemente zu ergänzen, z.B. Aktualisierung des Backlogs. Aspekte wie bestandene bzw. durchgeführte Unit-Tests sollten auf der Anforderungs-Ebene existieren, da sich diese Tests im Idealfall auf Stories beziehen.

Nachdem in Scrum nach jedem Sprint ein auslieferbares Inkrement existiert, ist es dort nicht notwendig über eine DoD auf der Release-Ebene nachzudenken. Da das auslieferbare Produktinkrement jede Iteration in der Praxis jedoch häufig nicht der Fall ist, gibt es auf dieser Ebene sinnvolle Elemente als Ergänzung zur Erfüllung der DoD aller beinhaltenden Sprints bzw. einzelnen Anforderungen. Ein Beispiel hierfür könnte das Deployment auf die Produktiv-Umgebung sein.

Es ist somit von der zeitlichen Dimension her klar der Fall, dass die jeweils darüberleigende Ebene als Hauptkriterium die Erfüllung der darunetrliegenden Ebenen hat. Als Beispiel beinhaltet die Sprint-Ebene als Kern die Erfüllung der DoD jeder einzelnen Anforderungen.

Inhaltliche Dimension – Programm-, Produkt/Projekt-, Team-Ebene: Sobald das Thema Skalierung eine Rolle spielt, also mehrere Teams ein Produkt entwickeln oder mehrere Projekte ein Programm bilden, bekommen beide Definitionen noch eine weitere Dimension.

Der Anwendungsbereich der DoR und DoD sollte im Grund immer alle Bereiche der Programm-Ebene umfassen, egal ob es ein Programm mit mehreren Produkten oder ein Produkt mit mehreren Teams ist. Jedoch sollten die verschiedenen Ebenen unterschiedlich abstrakt oder konkret sein.

Bleiben wir beim Beispiel mit Programm und Produkt: Zum Beispiel könnte auf Programm-Ebene in der DoD ein abstraktes Kriterium die Dokumentation der Umsetzung der UserStories sein, welche von allen unterliegenden Produkten erfüllt sein muss (Produkt-Ebene). Hierbei wir allerdings noch nichts über die konkrete Ausprägung erwähnt. Dies kann von Codekommentaren pro Methode im Quellcode des Produktes bis hin zu einer eigenen Wiki-Seite für jede Klasse reichen.

Wichtig bei dieser Verfeinerung ist der vorhandene Freiraum bzw. Flexibilität für die untere der beiden Ebene, ob es ein einzelnes Produkt in einem Programm ist oder ein Team in einem großen Projekt (Team-Ebene). Letzteres ist der deutlich schwierigere Fall, da die Ergebnisse der Teams später zu einem Gesamtprodukt zusammengebaut werden. Damit ist es immer ein schwieriger Trade-off zwischen möglichst konkreter Beschreibung auf oberer Ebene und genügend Freiraum für die darunterliegende Ebene.

Diese beiden Dimensionen einerseits zeitlich (Anforderung, Sprint, Release) und andererseits inhaltlich zeigen wie schnell die simplen Konzepte der DoR und DoD schnell komplexer werden können.