Definition of Done erarbeiten: Ein Workshop gegen „fast fertig“
Share
Eine Definition of Done erarbeitet ihr, indem ihr gemeinsam festlegt, welche überprüfbaren Qualitätsbedingungen ein nutzbares Increment erfüllen muss. Beginnt bei eurem Produkt und realen Fällen, nicht bei einer möglichst langen Musterliste. Eine gute Definition macht sichtbar, was fertig bedeutet und welche Arbeit dafür tatsächlich dazugehört.
Vielleicht ist ein Eintrag im Aufgabenboard erledigt, aber es fehlen noch Prüfung, Dokumentation oder ein notwendiger Integrationsschritt. Für eine Person ist er fertig, für die nächste erst vorbereitet. Das Wort „fast“ verdeckt dann Arbeit, die später überraschend auftaucht. Ein gemeinsamer Workshop hilft, diese unterschiedlichen Erwartungen offenzulegen.
Was die Definition of Done beschreibt
Die Definition of Done beschreibt den Qualitätszustand des Increments. Der Scrum Guide macht sie zum gemeinsamen Maßstab dafür, welche Arbeit zum Increment zählt. Vorgaben der Organisation bilden gegebenenfalls eine Mindestanforderung. Mehrere Scrum Teams am selben Produkt müssen eine gemeinsame Definition einhalten.
Die Definition ist damit mehr als eine persönliche Checkliste. Sie sollte für alle Beteiligten verständlich sein. Gleichzeitig muss sie zum Produkt passen. Eine Liste für Software lässt sich nicht unverändert auf ein anderes Produkt übertragen, nur weil beide Teams Scrum verwenden.
Unsere Scrum Cards helfen, diesen Zusammenhang gemeinsam zu erklären. Legt die passenden Karten zu Events, Artefakten und Rollen aus und besprecht, wo die Qualitätsvereinbarung eure Arbeit beeinflusst. Das Set umfasst 40 Lern- und Schätzkarten. Eure konkrete Definition schreibt ihr selbst; sie ist kein fertig ausgefülltes Dokument im Kartenset.
Definition of Done und Akzeptanzkriterien unterscheiden
Akzeptanzkriterien konkretisieren häufig die erwartete Funktion oder das Verhalten eines bestimmten Eintrags. Die Definition of Done beschreibt die geltenden Qualitätsbedingungen für das Increment. Beides kann zusammenwirken, beantwortet aber unterschiedliche Fragen.
Ein fiktives Beispiel: Für eine neue Suchfunktion könnte ein Akzeptanzkriterium festhalten, welche Treffer bei einer bestimmten Eingabe angezeigt werden. Eine allgemeine Qualitätsbedingung könnte verlangen, dass die Funktion in die bestehende Anwendung integriert und unter den vereinbarten Bedingungen geprüft ist. Das konkrete Produkt entscheidet, welche Nachweise sinnvoll und notwendig sind.
Wenn ihr beide Ebenen vermischt, entstehen entweder überladene allgemeine Listen oder zu schwache Qualitätsstandards. Prüft bei jedem vorgeschlagenen Punkt: Gilt er für das nutzbare Ergebnis grundsätzlich oder nur für diesen besonderen Anwendungsfall? Dokumentiert ihn dort, wo er für die Arbeit verständlich bleibt.
Den Workshop mit zwei echten Fällen vorbereiten
Bringt einen kürzlich abgeschlossenen Vorgang mit, bei dem später noch Arbeit auftauchte. Ergänzt einen Fall, der ohne Überraschungen nutzbar war. Sammelt den tatsächlichen Ablauf, ohne Personen als Verursachende vorzuführen. Interessant ist, welche Qualitätsannahmen sichtbar oder unsichtbar waren.
Ladet die Menschen ein, die an der Herstellung eines nutzbaren Ergebnisses beteiligt sind. Prüft außerdem vorhandene organisatorische Standards. Wenn eine wichtige Vorgabe unklar ist, kennzeichnet sie als offene Frage und holt die zuständige fachliche Perspektive dazu. Der Workshop sollte keine verbindlichen Anforderungen aus Unkenntnis wegverhandeln.
Reserviert 60 bis 90 Minuten für einen ersten Entwurf. Das ist ein praktischer Vorschlag für ein überschaubares Produkt, keine offizielle Scrum-Timebox. Bei komplexen Abhängigkeiten kann ein zweiter Termin nötig sein.
In fünf Schritten zu einem prüfbaren Entwurf
Erstens beschreibt ihr den Zustand, in dem das Ergebnis tatsächlich nutzbar ist. Wer verwendet es und unter welchen Bedingungen? Zweitens betrachtet ihr die beiden mitgebrachten Fälle. Welche fehlende Bedingung führte im problematischen Fall zu zusätzlicher Arbeit? Was war im guten Fall bereits geklärt?
Drittens formuliert ihr daraus mögliche Qualitätskriterien. Viertens prüft ihr für jedes Kriterium, welcher Nachweis seine Erfüllung zeigt. Fünftens testet ihr den Entwurf an einem weiteren konkreten Eintrag. Wenn ihr nicht eindeutig sagen könnt, ob das Kriterium erfüllt ist, braucht die Formulierung mehr Präzision.
| Unklare Formulierung | Hilfreiche Nachfrage | Richtung einer prüfbaren Formulierung |
|---|---|---|
| Ausreichend getestet | Welche relevanten Fälle und Bedingungen? | Vereinbarte Prüfungen durchgeführt, Ergebnisse sichtbar |
| Gut dokumentiert | Welche Information wird für Nutzung oder Betrieb gebraucht? | Erforderliche Informationen am benannten Ort aktualisiert |
| Technisch fertig | Welche Integration und Nutzung sind noch offen? | Mit bestehendem Produkt verbunden und nutzbar |
| Qualität stimmt | Welche Maßstäbe gelten konkret? | Benannte Qualitätsbedingungen nachweislich erfüllt |
Die rechte Spalte ist eine Formulierungshilfe und noch keine vollständige Definition. Ergänzt eure konkreten Bedingungen. Eine allgemeine Blogvorlage kann eure Produkt- und Organisationskenntnis nicht ersetzen.
Einen Nachweis für jedes Kriterium vereinbaren
Ein Kriterium wird praktisch nutzbar, wenn klar ist, wie seine Erfüllung erkennbar ist. Das kann ein dokumentiertes Prüfergebnis, eine überprüfte Integration oder eine aktualisierte Information sein. Vermeidet Nachweise, die nur bestätigen, dass jemand ein Kästchen angeklickt hat, ohne die eigentliche Qualität zu prüfen.
Legt auch fest, wo der Nachweis liegt. Wenn das Team im Planning den Aufwand berücksichtigt, später aber niemand die Erfüllung nachvollziehen kann, bleibt die Vereinbarung schwach. Der Ort sollte in euren normalen Arbeitsfluss passen und nicht eine zusätzliche isolierte Dokumentation erzeugen.
Automatisierung kann wiederkehrende Prüfungen erleichtern, ist aber keine Voraussetzung für jede Qualitätsvereinbarung. Entscheidend ist, dass die erforderliche Prüfung tatsächlich stattfindet. Umgekehrt beweist eine erfolgreiche automatisierte Prüfung nur das, was sie abdeckt. Besprecht offene Aspekte ausdrücklich.
Fiktives Beispiel: Eine neue Exportfunktion
Ein Team hat einen Datenexport als fertig markiert. Bei der ersten Nutzung zeigt sich, dass eine große Datei nicht verarbeitet werden kann und die Anleitung einen veralteten Dateinamen nennt. Im Workshop erkennt das Team zwei unterschiedliche Lücken: Die vereinbarten Nutzungsbedingungen waren unklar und die für die Verwendung nötige Information wurde nicht mitgeführt.
Das Team präzisiert seine Qualitätsbedingungen für relevante Datenmengen und notwendige Nutzungsinformationen. Es prüft außerdem, ob diese Bedingungen für das gesamte Produkt gelten oder ob ein Teil davon nur die konkrete Exportfunktion betrifft. So entsteht eine passende Kombination aus allgemeiner Definition und eintragsspezifischen Kriterien.
Beim nächsten ähnlichen Eintrag berücksichtigt das Team die Arbeit von Anfang an. Der Nutzen liegt nicht darin, dass die Liste länger geworden ist, sondern dass vorher versteckte Arbeit sichtbar und planbar wird. Die Anleitung zum Sprint Planning hilft, diese Arbeit in die Planung einzubeziehen.
Wenn ein Kriterium heute noch nicht erfüllt werden kann
Verwechselt den aktuellen verbindlichen Maßstab nicht mit einer Wunschliste für später. Ein unerfüllbares Kriterium einfach aufzuschreiben erzeugt noch keine Qualität. Macht das Hindernis sichtbar und klärt, welche Verbesserung oder organisatorische Unterstützung nötig ist. Verbindliche Mindestanforderungen dürfen dabei nicht aus Bequemlichkeit als optional behandelt werden.
Wenn euch Fähigkeiten, Zugänge oder eine praktikable Integration fehlen, gehört das Problem in die gemeinsame Verbesserungsarbeit. Plant konkrete Schritte und prüft deren Wirkung. Eine separate Liste geplanter Verbesserungen kann helfen, den gültigen Stand und den angestrebten Stand auseinanderzuhalten.
Die Definition sollte nicht bei jedem Zeitdruck stillschweigend gelockert werden. Wenn ein Ergebnis den gültigen Maßstab nicht erfüllt, bezeichnet es entsprechend. Ein ehrlicher Status hilft mehr als eine grüne Anzeige, deren Bedeutung niemand mehr kennt.
Die neue Fassung für die nächste Arbeit verfügbar machen
Gebt der Definition ein Datum und einen eindeutigen Ablageort. Geht die geänderten Kriterien vor der nächsten Planung kurz gemeinsam durch. Prüft, ob daraus zusätzlicher Aufwand oder neue Abhängigkeiten entstehen, die berücksichtigt werden müssen.
Neue Teammitglieder sollten die Bedeutung anhand eines konkreten Ergebnisses kennenlernen. Eine bloße Aufforderung, die Liste zu lesen, zeigt noch nicht, ob dieselben Qualitätsvorstellungen entstehen. Lasst sie einen Fall einordnen und besprecht offene Fragen. Dadurch überprüft ihr gleichzeitig die Verständlichkeit eurer Formulierungen.
Häufige Fragen zur Definition of Done
Wer erarbeitet die Definition?
Das Scrum Team benötigt ein gemeinsames Verständnis und berücksichtigt geltende Organisationsstandards. Die Developers müssen die Definition einhalten. Relevante fachliche Perspektiven können bei der Formulierung und Prüfung helfen. Eine isoliert von außen zugeschickte Liste ohne gemeinsames Verständnis reicht im Alltag oft nicht aus.
Wie oft sollte sie geändert werden?
Wenn neue Erkenntnisse oder veränderte Anforderungen eine Anpassung nötig machen. Nutzt dafür bewusst einen geeigneten gemeinsamen Termin, etwa im Rahmen eurer Verbesserungsarbeit. Dokumentiert die gültige Fassung. Die Scrum-Rollenübersicht hilft bei der Einordnung der Verantwortlichkeiten.
Womit starten wir morgen?
Nehmt einen Fall, der trotz „fertig“ noch einmal zurückkam. Beschreibt die fehlende Bedingung und einen passenden Nachweis. Damit beginnt ihr bei einem realen Problem und könnt unmittelbar prüfen, ob eure neue Vereinbarung künftig Klarheit schafft.
