Was ist die Definition of Done?
Schon mal etwas ausgeliefert und dann gemerkt, dass es gar nicht richtig fertig war? Eine Definition of Done (DoD) ist die gemeinsame Liste von Kriterien, die jede Arbeit erfüllen muss, bevor jemand sie als abgeschlossen bezeichnet. Sie gilt für jede User Story, jedes Feature und jedes Inkrement. So bedeutet „fertig“ immer dasselbe, egal wer die Arbeit erledigt hat. In Scrum ist die Definition of Done der Qualitätsmaßstab für jedes Inkrement. Wenn ihr sie schriftlich festhaltet, enden die Diskussionen à la „Ist das jetzt fertig?“ im Review, und versteckte Arbeit wie fehlende Tests oder Dokumentation rutscht nicht mehr in den nächsten Sprint. In dieser Session erarbeiten Entwickler, Tester, Designer und Product Owner die Liste gemeinsam. Dadurch deckt sie genau die Schritte ab, von denen jede Rolle weiß, dass sie gern übersprungen werden. Das Board hat vier Spalten: Qualitätskriterien, Dokumentation & Kommunikation, Tests & Validierung sowie Deployment & Release-Bereitschaft. Alle tragen Kriterien bei, anschließend gruppiert das Team sie und stimmt darüber ab, um sich auf die Liste zu einigen. Versteht das Ergebnis als lebendes Dokument und überarbeitet es, wenn sich eure Tools und Standards ändern. Hintergrundinfos findet ihr im Leitfaden von Scrum.org zur Definition of Done.
Definition of Done: Format für die Zusammenarbeit
Qualitätskriterien
Welche Qualitätsstandards muss Arbeit erfüllen, um fertig zu sein?
Sammelt die technischen und qualitativen Prüfungen, die jede Arbeit bestehen muss, etwa Code-Review, Testabdeckung, Performance und Coding-Standards. Fragt: „Was würde uns die Sicherheit geben, dass das in Produktion nicht kaputtgeht?“ So kommen unausgesprochene Erwartungen auf den Tisch und lassen sich messbar machen.
Dokumentation & Kommunikation
Was muss dokumentiert oder geteilt werden, bevor es fertig ist?
Hier geht es darum, was aufgeschrieben oder anderen mitgeteilt werden muss, bevor Arbeit als fertig gilt. Fragt, wer von einer Änderung wissen muss und was danach vorhanden sein sollte. Teams lassen diesen Teil oft aus, also fragt ruhig nach Lücken aus der Vergangenheit.
Tests & Validierung
Wie prüfen wir, dass die Arbeit wirklich funktioniert?
Einigt euch auf die Prüfungen, die belegen, dass die Arbeit tut, was sie soll. Denkt über automatisierte Tests hinaus an manuelle, explorative und Abnahmetests und legt fest, wer abnimmt und in welcher Umgebung.
Deployment & Release-Bereitschaft
Was muss gegeben sein, um die Arbeit sicher zu releasen?
Legt fest, was erfüllt sein muss, bevor Arbeit live geht. Sprecht über Deployment, Monitoring, Rollback-Pläne und darüber, wer sich nach dem Release darum kümmert. Damit schließt ihr die Lücke zwischen fertigem Code und einem Feature, das die Leute tatsächlich nutzen können.
Wann sollte diese Retrospektive durchgeführt werden?
- Wenn sich ein neues Team bildet und sich von Anfang an auf Qualitätsstandards einigen muss.
- Wenn Arbeit immer wieder neu geöffnet wird oder Bugs in Produktion landen. Das bedeutet meist, dass die Vorstellungen davon, was fertig ist, auseinandergehen.
- Vor dem Start eines neuen Projekts, damit sich das Team auf den Maßstab einigt, bevor die Arbeit beginnt.
- Beim Onboarding neuer Teammitglieder, die die Qualitätserwartungen des Teams kennenlernen müssen.
- Wenn eine Retrospektive zeigt, dass Leute im Team unterschiedlich verstehen, wann etwas abgeschlossen ist.
Vorschläge für Fragen zum Icebreaker
- Wenn „fertig“ eine Persönlichkeit hätte, welche wäre es: Perfektionist, Pragmatiker oder Last-Minute-Held?
- Was ist das Überraschendste, bei dem du mal festgestellt hast, dass es gar nicht wirklich fertig war?
Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →
Ideen und Tipps für Ihre Retrospektive
- Erarbeitet die Definition of Done mit dem ganzen Team, damit alle sich dafür verantwortlich fühlen. Lasst sie nicht von einer einzelnen Person schreiben.
- Haltet die Kriterien realistisch. Eine DoD, die das Team nie erfüllt, wird ignoriert.
- Formuliert jedes Kriterium so konkret, dass es sich überprüfen lässt und niemand darüber streiten muss, ob es erfüllt ist.
- Überarbeitet sie alle paar Sprints, wenn sich eure Standards und Tools ändern.
- Gebt allen vor der Gruppendiskussion Zeit, eigene Ideen einzubringen, damit auch die Stilleren zu Wort kommen.
- Trennt sie von den Akzeptanzkriterien. Die DoD gilt für alle Arbeit, Akzeptanzkriterien gehören zu einer einzelnen Story.
Häufig gestellte Fragen
Was ist eine Definition of Done im agilen Arbeiten?
Worin unterscheidet sich die Definition of Done von Akzeptanzkriterien?
Wer sollte an der Erstellung der Definition of Done beteiligt sein?
Wie oft sollten wir unsere Definition of Done aktualisieren?
Wie lange dauert es, eine Definition of Done zu erstellen?
Verwandte Vorlagen
Sammle umsetzbares Feedback zu deinem Sprint Review.
Rose-Bud-Thorn-Retrospektive
Benennt Erfolge, erste Chancen und Schmerzpunkte eures Teams in einer Session.
What? So What? Now What?-Retrospektive
Von dem, was passiert ist, zu dem, was ihr als Nächstes tut.
FLAP-Retrospektive
Erkenntnisse, Erfolge und Probleme reflektieren und dann die nächsten Schritte planen