Ansichten: 2
Zusammenfassung – Fehlende Definition of Ready und Definition of Done verursachen Missverständnisse, Verzögerungen und mangelnde Planbarkeit zwischen Fachbereichen und Entwicklung – auf Kosten von Qualität und Vertrauen. Mit Vorgaben beim Backlog-Einstieg – Mock-ups, Geschäftsregeln und Akzeptanzkriterien (DoR) – und verpflichtenden automatisierten Tests, Code-Reviews sowie Dokumentation (DoD) verwandeln sich agile Rituale in operative Verträge, die den Ablauf stabilisieren und Teams in die Verantwortung nehmen. Lösung: DoR und DoD mithilfe kollaborativer Workshops, messbarer Kennzahlen und agiler Governance einführen, um späte Rückmeldungen, Sprintunterbrechungen und Governance-Schulden deutlich zu reduzieren.
Im Kontext, in dem digitale Transformation zum Imperativ geworden ist, wird Agilität bisweilen als eine Reihe theoretischer Rituale wahrgenommen, die von den operativen Herausforderungen entfernt sind. Doch die Definition of Done (DoD) und die Definition of Ready (DoR) sind nicht bloß Checkboxen im Scrum-Backlog, sondern explizite Verträge, die die Anforderungen der Fachbereiche, des Produkts und der Technik in Einklang bringen.
Sie stellen die gelieferte Qualität, die Vorhersehbarkeit und die kollektive Verantwortlichkeit sicher. Dieser Artikel zeigt, wie DoD und DoR zu Mechanismen operativer Governance werden und implizite Missverständnisse vermeiden. Beispiele aus Schweizer Organisationen belegen ihren Einfluss auf die Verringerung von Reibungsverlusten und die Stabilisierung des Flusses.
Unklarheiten mit DoR und DoD eingrenzen
Ohne eindeutige Definitionen von „Ready“ und „Done“ arbeiten Teams oft nach Augenmaß und liefern verschobene Ergebnisse. DoR und DoD fungieren als explizite Verträge, die Missverständnisse ausräumen und den Flow zwischen Business, Produkt und Technik stabilisieren.
Missverständnisse ohne klare Definitionen
In vielen Organisationen bedeutet „Done“ nicht dasselbe für das Technik-Team und für die Fachbereiche. Diese Unklarheit erzeugt unvollständige oder ungetestete Lieferergebnisse, die Kettenreaktionen von Feedback auslösen. Wird eine User Story ohne genaue Festlegung als „Ready“ eingestuft, fehlt dem Team der notwendige Kontext für den Implementierungsstart.
Akkumulierte Missverständnisse führen letztlich zu Frustration zwischen Product Ownern und Entwicklern. Jede Seite ist der Ansicht, die andere habe ihre Zusagen nicht eingehalten, ohne dass eine wirklich schuld wäre. Diese Spannungen verringern die Effektivität der agilen Zeremonien und verzögern die Time-to-Market.
Eine gemeinsame Definition von „Ready“ und „Done“ erlaubt es, den Bedarf vor dem Sprint präzise zu antizipieren und Nachjustierungen am Ende des Zyklus zu minimieren. Ab dann weiß jedes Teammitglied, wann eine Story ausreichend detailliert ist, um gestartet zu werden, und wann die Arbeit als abgeschlossen markiert werden kann.
DoD und DoR als Säulen agiler Governance
DoD und DoR strukturieren den Workflow, indem sie den Übergang der User Stories in jeder Phase des Prozesses rahmen. Sie gleichen kollektiv geschlossenen Verträgen, die die Anwendung bewährter Praktiken und die Einhaltung der Anforderungen der Fachbereiche sicherstellen. DoR steuert den Eintritt des Backlogs in den Sprint, während DoD den Austritt aus dem Sprint anhand eines Satzes messbarer Kriterien validiert.
Dank dieser Definitionen wird die Planung vorhersagbarer und die Schätzungen zuverlässiger. Das Team kann sich auf die Wertlieferung konzentrieren, ohne improvisieren zu müssen oder informelle Kontrollpunkte zu vermehren. Anomalien werden frühzeitig erkannt, was das Vertrauen der Stakeholder stärkt.
Die Einführung dieser Säulen agiler Governance schafft keine überflüssige Bürokratie, sondern etabliert eine gemeinsame Disziplin. Jedes Kriterium dient als Orientierungspunkt für Sprint-Reviews, automatisierte Tests und Deployments und stimmt so das Ausführungstempo auf die Qualitätsziele ab.
Beispiel für Klarstellung in einem Schweizer KMU
Ein in der Industrie tätiges Schweizer KMU hatte Mühe, seine Auftragsverwaltungsmodule an die internen Projektleiter zu liefern. Die Deliverables wurden als unvollständig bewertet, da die Fachbereiche eine detaillierte Dokumentation erwarteten, die in der als „Done“ deklarierten Version fehlte. Dadurch häuften sich Feedback-Schleifen am Ende des Sprints und der Lieferpipeline wurde verlangsamt.
Das Team formalisierte daraufhin eine DoR, die vor Start eines Tickets die Bereitstellung von Mockups, Business-Regeln und erwarteten Leistungskriterien festlegte. Die DoD wurde um Anforderungen an Unit-Tests, Code-Reviews und die Aktualisierung der Anwenderdokumentation erweitert. Diese Definitionen wurden in Co-Creation-Workshops vorgestellt und gemeinsam validiert.
Diese Initiative reduzierte das späte Feedback innerhalb von zwei Monaten um über 60 % und beschleunigte den Lieferrhythmus, ohne die Arbeitsbelastung zu erhöhen. Sie zeigt, wie das Eingrenzen von Unklarheiten agile Rituale in wertschöpfende Governance-Rahmen überführt.
Das minimale Qualitätsniveau mit der Definition of Done (DoD) festlegen
Die DoD ist keine einfache Checkliste, sondern die Darstellung eines von allen Stakeholdern geteilten Mindestqualitätsniveaus. Sie definiert den Punkt, ab dem eine Arbeit präsentiert, getestet oder produktiv gesetzt werden kann, ohne späte Rückläufe oder Korrekturen auszulösen.
Falsche „Done“-Tickets vermeiden
Ein Ticket, das ohne explizite Kriterien als „Done“ deklariert wird, führt zu kosmetischen Demos, bei denen die Funktion zwar scheinbar funktioniert, aber an Robustheit fehlt. Solche falschen „Done“-Fälle verursachen spätes Feedback und ungeplante Reparatur-Sprints. Die DoD greift diese Fallstricke gezielt auf, indem sie die minimal erforderliche Abdeckungsrate für automatisierte Tests und die Dokumentation festlegt.
Anpassbare und messbare Kriterien
Die DoD schreibt keinen starren Rahmen vor, sondern bietet eine Reihe von Kriterien, die das Team entsprechend seiner Reife anpassen kann. Beispielsweise kann ein Testabdeckungswert von 70 % auf 80 % angehoben werden, je nach Erfahrungsrückmeldungen und identifizierten Business-Risiken. Jedes Kriterium muss messbar sein, um unterschiedliche Interpretationen zu vermeiden.
Zu den Kriterien können die Anzahl der Code-Reviews, die Aktualisierung der funktionalen Dokumentation, die Automatisierung von Regressionstests und die Vorbereitung einer strukturierten Demo gehören. Diese Modularität ermöglicht es, die Disziplin schrittweise zu erhöhen, ohne die DoD in eine dogmatische Vorschrift zu verwandeln. Das Team verfolgt die Entwicklung der Indikatoren, um seine Ziele anzupassen.
Im Laufe der Sprints speisen diese Indikatoren ein einfaches Reporting, das die Qualitätsverbesserung aufzeigt und auf Abweichungen aufmerksam macht. Dieser Ansatz wandelt die DoD in einen Reifegrad-Spiegel, in dem jedes Kriterium als Hebel für kontinuierliche Verbesserung fungiert.
Auswirkungen auf Demonstrationen und Tests
Ein Unternehmen aus dem Dienstleistungssektor stellte fest, dass seine Demonstrationen systematisch mit „ausgedünnten“ oder unvollständigen Funktionen endeten. Das Feedback nach dem Sprint machte bis zu 30 % der Restarbeitszeit aus, die für die Behebung der von den Fachbereichen identifizierten Mängel aufgewendet wurde. Diese Situation schwächte das Vertrauen zwischen den Teams.
Nach Einführung einer DoD, die die minimale Abdeckung durch Unit- und Integrationstests sowie die operative Validierung in einer Spiegelumgebung festlegte, gingen die Feedback-Schleifen am Sprintende um 75 % zurück. Die Demonstrationen wurden zu echten Validierungssessions und nicht zu bloßen Schaufenstern. Jeder Inkrement war tatsächlich einsatzbereit oder bereit für die Produktion.
Dieses Beispiel verdeutlicht, dass die DoD den Lieferrhythmus nicht bremste, sondern die falschen „Done“-Fälle eliminierte und die Zuverlässigkeit des Prozesses stärkte.
Edana: Strategischer Digitalpartner in der Schweiz
Wir begleiten Unternehmen und Organisationen bei ihrer digitalen Transformation.
Die DoD als Instrument kollektiven Lernens
Die DoD entwickelt sich mit der Reife des Teams weiter und nutzt vergangene Vorfälle, um die Standards zu verfeinern. Dieser Mechanismus verwandelt Fehler in Hebel für kontinuierliche Verbesserung, ohne dogmatisch zu werden.
Aus vergangenen Vorfällen lernen
Jeder Fehler oder Produktionsvorfall birgt eine wertvolle Lektion für das Team. Durch die systematische Analyse der Ursachen kann man neue Kriterien in die DoD aufnehmen und Wiederholungen derselben Fehler verhindern. Dieser Ansatz stärkt die Kultur der Transparenz.
Zum Beispiel kann das Auftreten eines kritischen Bugs während der Abnahme zur Aufnahme eines spezifischen automatisierten Tests und zur Festlegung eines minimalen Performanceniveaus führen. Diese Erkenntnisse werden in einer Sprintabschluss-Review dokumentiert und sofort in die DoD übernommen. So macht das Team Sprint für Sprint Fortschritte.
Mit den fortlaufenden Anpassungen wird die DoD zu einem gemeinsamen Lernkapital, das jede Iteration robuster macht. Dieser iterative Ansatz fördert gegenseitiges Vertrauen und richtet die Weiterentwicklung konsequent an den realen Anforderungen des Produkts aus.
DoD mit wachsender Reife weiterentwickeln
Ein unerfahrenes Team kann mit einer schlanken DoD starten, die nur Unit-Tests und Code-Reviews umfasst. Mit zunehmender Disziplin können weitere Kriterien wie Integrationstestabdeckung oder Sicherheitsvalidierung hinzukommen. Diese Weiterentwicklung sollte außerhalb der Sprints geplant werden, um Unterbrechungen im Rhythmus zu vermeiden.
Es ist entscheidend, inkrementelle Verbesserungen von umfassenderen Revisionen der DoD zu unterscheiden. Kleine Anpassungen lassen sich in den Sprint-Reviews beschließen, während größere Änderungen eigene Workshops erfordern. Diese Governance bewahrt die Prozessstabilität und ermöglicht gleichzeitig eine schrittweise Kompetenzsteigerung.
Schließlich kann die DoD eines reifen Teams Performance-Schwellenwerte, Sicherheitsaudits und die Validierung einer umfassenden technischen Dokumentation umfassen. Jedes neue Kriterium spiegelt die gewonnene Expertise wider und gewährleistet ein stets höheres Qualitätsniveau.
Gleichgewicht zwischen Disziplin und Flexibilität
Ist die DoD zwar unerlässlich für die Zuverlässigkeit, darf sie nicht zur Innovations- oder Reaktivitätsbremse werden. Kollektive Intelligenz steht über der Regel und kann in kritischen Fällen temporäre Anpassungen rechtfertigen, um Fristen oder geschäftliche Vorgaben einzuhalten.
Solche Ausnahmeregelungen müssen strikt geregelt und dokumentiert werden, um keine gefährlichen Präzedenzfälle zu schaffen. Sie bleiben Ausnahmen und werden in den Retrospektiven nachverfolgt, um zu entscheiden, ob diese Kriterien in die Standard-DoD übernommen werden.
So behält die DoD ihre Rolle als qualitätssichernder Rahmen und passt sich dabei an die Projektrealität und strategische Prioritäten an, ohne je in lähmenden Formalismus abzugleiten.
Eintritt und Flow mit der Definition of Ready (DoR) absichern
Die DoR stellt sicher, dass jedes Backlog-Element ohne Improvisation oder Unterbrechungen im Sprint entwickelt werden kann. Sie fungiert als Vertrag zwischen dem Product Owner und dem Team, erhöht die Planbarkeit und reduziert Fehleinschätzungen.
Bedarf antizipieren, um Improvisationen zu vermeiden
Eine schlecht definierte User Story führt zu endlosen Klärungssitzungen, unterbricht den Entwicklungsfluss und erhöht das Risiko von Abweichungen. Die DoR verlangt, dass Mockups, Geschäftsregeln und Akzeptanzkriterien vor dem Einbringen der Story in einen Sprint vorliegen. Diese Vorbereitung im Vorfeld sichert die Arbeit des Teams.
Sie begrenzt endlose Sprint-Planungsmeetings, indem die Vorbereitungsarbeit vor dem Planning-Meeting gebündelt wird. Die Diskussionen konzentrieren sich auf den geschätzten Aufwand und den Business-Nutzen statt auf das Verständnis der Anforderungen. Das Team kann sich so auf die Umsetzung fokussieren.
Über die bessere Klarheit hinaus fördert die DoR die Zusammenarbeit zwischen den Fachbereichen und dem Product Owner, um Annahmen zu hinterfragen und die Priorität der Stories vorab anzupassen. Dieser frühe Dialog stärkt die Akzeptanz der Roadmap.
DoR als Vertrag zwischen Product Owner und Team und Hebel für Planbarkeit
Die DoR formalisiert, was der Product Owner liefern muss: Story-Beschreibung, funktionale Aufteilung, Dokumentation von Abhängigkeiten und erste Schätzung. Das Team bestätigt daraufhin seine Lieferfähigkeit entsprechend diesen Kriterien und erklärt die Story als „Ready“ für den Sprint. Diese Vertragsvereinbarung erhöht die Planbarkeit.
Unterbrechungen im Sprint zur Klärung von Anforderungen werden zur Ausnahme. Jede Story durchläuft einen Vorbereitungsschritt, der Unterschätzungen und Nacharbeit reduziert. Die Planung wird zuverlässiger und die Sprintziele werden häufiger erreicht.
Zudem fungiert die DoR als Richtschnur gegen zu vage oder zu große Stories. Sie regt dazu an, umfangreiche Funktionen in kleinere Iterationen zu unterteilen, um ein nachhaltiges Arbeitstempo und ständige Transparenz über den Fortschritt zu ermöglichen.
Reibungsverluste reduzieren und konkretes Beispiel
Ein Unternehmen im Finanzdienstleistungsbereich hatte Schwierigkeiten, seine quartalsweisen Lieferzusagen einzuhalten, weil Stories unzureichend definiert waren. Die Sprints wurden häufig unterbrochen, da Mockups und Prozessdiagramme für die Entwicklung fehlten. Diese Situation verursachte einen wachsenden Vorbereitungsstau.
Nach Einführung einer DoR, die die Verfügbarkeit von Mockups, die Validierung der Geschäftsregeln und eine kollaborative Schätzung vorsah, ließen sich Unterbrechungen um den Faktor drei reduzieren. Der Aufwand für Klärungspunkte sank um 40 %, und die Teams konnten einen gleichmäßigen Lieferrhythmus halten.
Dieser Fall zeigt, wie die DoR den Entwicklungsfluss schützt und das Vertrauen zwischen Product Owner und Team stärkt, während die Sprint-Planbarkeit verbessert wird.
Agilität und operative Zuverlässigkeit in Einklang bringen
DoR und DoD strukturieren den agilen Flow, indem sie den Einstieg und den Abschluss jeder User Story absichern. Die DoR stellt sicher, dass das Backlog einsatzbereit ist und Improvisationen verhindert, während die DoD den minimalen Qualitätsstandard festlegt und falsche „Done“-Fälle eliminiert. Gemeinsam stabilisieren diese Konventionen das Arbeitstempo, reduzieren die unsichtbare Schuldenlast und stärken das Vertrauen der Stakeholder.
Das Fehlen einer DoR oder DoD über längere Zeit weist oft auf organisatorische Unklarheiten, fehlende Abstimmung oder Governance-Schulden hin. Wachsende Organisationen, Projekte mit hohen Anforderungen und Multi-Stakeholder-Kontexte profitieren besonders davon, diese Definitionen zu formalisieren. Unsere Edana-Experten begleiten Sie bei der Anpassung und Weiterentwicklung dieser Rahmen, damit sie Ihrem Produkt und Ihrer Agilität dienen.
Besprechen Sie Ihre Herausforderungen mit einem Edana-Experten
