Definition of Done: Was sie ist und wie man sie verwendet

Hier sind die wichtigsten Merkmale einer effektiven Definition von "erledigt":

• Transparenz: Jeder im Team und alle relevanten Stakeholder können sie jederzeit einsehen, lesen und nachschlagen.
• Messbar: Jedes Kriterium ist binär. Die Arbeit erfüllt es entweder oder nicht, aber die Schwellenwerte bei quantitativen Kriterien sollten wohlüberlegt gewählt werden. Ein Ziel von 80 % Codeabdeckung ist in der Umsetzung binär, aber die Entscheidung für 80 % statt 70 % oder 90 % sollte bewusst getroffen werden.
• Allgemein verständlich: Jedes Mitglied des Scrum-Teams muss jedes Kriterium auf die gleiche Weise interpretieren können.
• Konsistent angewandt: Die gleiche Checkliste muss auf jedes Ergebnis und jeden Product-Backlog-Eintrag angewendet werden. 
• Im Sprint erreichbar: Die Kriterien sollten realistisch genug sein, dass das Team sie innerhalb eines Sprints oder einer Iteration erfüllen kann.

In Softwareentwicklungsprojekten liegt die Verantwortung für die Definition von "erledigt" (Definition of Done) typischerweise bei den Entwicklern, da sie für die Einhaltung verantwortlich sind. Dennoch sollten Product Owner und Scrum Master ebenfalls ihren Beitrag leisten.

Wenn Ihre Organisation eigene Standards für die Definition von "erledigt" (Definition of Done) besitzt, muss jedes Scrum-Team diese mindestens als Grundlage einhalten. Teams können jederzeit strengere Kriterien hinzufügen, aber die organisatorische Mindestanforderung darf nicht unterschritten werden.

Warum die Definition von "erledigt" wichtig ist

Eine klare Definition von "erledigt" (Definition of Done) ist wichtig, weil sie verhindert, dass teilweise abgeschlossene Arbeiten durchrutschen, und einen gemeinsamen Qualitätsstandard schafft.

Hier sind weitere Gründe, warum eine gemeinsame Definition von "erledigt" entscheidend ist:

• Wirkt als integrierte Qualitätskontrolle: Jeder Eintrag muss den gleichen Standard erfüllen, bevor er als fertig gilt. Das verhindert, dass halbfertige Arbeiten in Ihr Produktinkrement gelangen und sich als technische Schulden ansammeln.
• Beseitigt Unklarheiten: Wenn das Team eine Definition teilt, gibt es keine Situationen mehr, in denen unterschiedliche Auffassungen Geschwindigkeit oder Qualität beeinflussen. Eine gemeinsame Definition von "erledigt" bedeutet weniger Konflikte, weniger Überraschungen und bessere Demos.
• Verbessert Prognosen: Wenn „fertig“ in jedem Sprint das Gleiche bedeutet, kann die Geschwindigkeit des Teams sicher prognostiziert und Releases ohne zusätzliche Puffer für Nacharbeiten geplant werden.
• Stärkt das Vertrauen der Stakeholder: Wenn Product Owner, Führungskräfte und externe Stakeholder erkennen, dass Ihr Team einen klaren Qualitätsstandard einhält, stärken Sie das Vertrauen in Ihre Arbeit. 
• Verhindert Integrationschaos: Wenn Sie in einem Modus arbeiten, in dem das Team seine Arbeit in ein gemeinsames Inkrement integrieren muss, ist ein gemeinsames Verständnis der Definition von "erledigt" die Grundlage für konsistente, auslieferbare Inkremente. 

Führen Sie intelligenter im Zeitalter der KI

Treten Sie der DPM-Community bei und erhalten Sie Zugang zu exklusiven Inhalten, praxisnahen Vorlagen, Mitglieder-Events und wöchentlichen Leadership-Insights – die Teilnahme ist kostenlos.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Company

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Wie erstellt man eine Definition von "erledigt"?

Dies sind die wichtigsten Schritte bei der Erstellung einer Definition von "erledigt" (Definition of Done).

1. Überprüfen Sie Ihren aktuellen Workflow: Erfassen Sie jeden Schritt, den Ihre Arbeit bereits durchläuft, bevor sie in die Produktion gelangt. Sprechen Sie mit Entwicklern, Testern, Designern und allen anderen, die mit der Arbeit in Berührung kommen. Sie werden informelle Qualitätsschritte entdecken, die formell festgelegt werden sollten.
2. Identifizieren Sie unverzichtbare Qualitätskriterien: Legen Sie fest, welche Aktivitäten bei jedem Arbeitsschritt durchgeführt werden müssen. Dazu gehören in der Regel Code-Reviews, automatisierte Tests, Aktualisierungen der Dokumentation und Sicherheitsprüfungen. Seien Sie ehrlich, was Sie aktuell auslassen.
3. Erstellen Sie die Checkliste gemeinsam: Bringen Sie das gesamte Team zusammen und erarbeiten Sie die Liste gemeinsam an einem Whiteboard oder in einem geteilten Dokument, in dem alle Punkte ergänzen, hinterfragen und direkt verfeinern können. Eine im Konsens getragene Definition of Done hält dem Druck deutlich besser stand als eine, die gegen Einwände durchgesetzt wurde.
4. Überprüfen Sie die Vorgaben mit den Unternehmensstandards: Vergleichen Sie Ihren Entwurf mit allen unternehmensweiten Qualitätsrichtlinien, regulatorischen Anforderungen oder Branchenstandards, die Ihr Produkt erfüllen muss. Wenn Ihre Organisation bereits eine grundlegende Definition of Done hat, starten Sie dort und bauen Sie darauf auf.
5. Machen Sie sie sichtbar: Hängen Sie die Definition dort aus, wo Ihr Team täglich arbeitet. Das kann ein Poster an der Wand sein, eine angepinnte Nachricht in Slack oder ein Panel im Projektmanagement-Tool.
6. Verpflichten Sie sich, sie durchzusetzen: Eine Definition of Done, die bei Zeitdruck übergangen wird, ist schlimmer als gar keine, denn sie erzeugt eine trügerische Qualität. 

Beispiele für Definition of Done

Hier sind einige Beispiele für Definitionen of Done für verschiedene Projekttypen:

Definition of Done für Softwareentwicklungsprojekte

Softwareprojekte stehen einer Vielzahl von Qualitätsrisiken gegenüber: Fehler, Sicherheitslücken, Leistungsverluste und Integrationsprobleme. Die Definition of Done eines Softwareteams muss den kompletten Weg vom Code bis zum auslieferbaren Zustand abdecken.

Das könnte wie folgt aussehen:

• Jeder Code wurde geschrieben und von mindestens einem weiteren Entwickler geprüft
• Unittests mit vereinbarter Abdeckungsquote bestanden
• Integrationstests in der CI/CD-Pipeline erfolgreich
• Keine offenen Fehler mit kritischer oder hoher Priorität
• Technische Dokumentation entsprechend der Änderungen aktualisiert
• Code ist in den Haupt-Branch zusammengeführt
• Product Owner hat die Arbeit geprüft und akzeptiert
• Leistungsbenchmarks gemäß vereinbarten Grenzwerten eingehalten

Definition of Done für Marketingprojekte 

Marketing-Arbeiten haben oft Compliance-, Marken- und Messungsdimensionen, die sich von der Software unterscheiden. 

So könnte eine Definition of Done für ein Marketingprojekt aussehen:

• Inhalte wurden vom Rechtsteam geprüft und freigegeben
• SEO-Checkliste abgearbeitet, inklusive Meta-Beschreibungen, Alternativtext und internen Links
• Alle Assets sind im CMS hochgeladen und korrekt formatiert
• Analytics-Tracking ist eingerichtet und in der Staging-Umgebung geprüft
• Finaler Text von einem zweiten Teammitglied korrekturgelesen
• Checkliste für Kampagnenstart wurde vom Teamleiter abgenommen

Definition of Done für Designprojekte 

Designteams benötigen eine Definition of Done, die die Brücke zwischen kreativem Anspruch und technischer Übergabe schlägt. Ohne diese kommen Designs häufig unvollständig in die Entwicklungsphase – mit fehlenden Spezifikationen, nicht geprüfter responsiver Darstellung oder Barrierefreiheitslücken, die erst zu spät erkannt werden.

Hier ein Beispiel für eine Definition of Done für ein Designprojekt:

• Design gemäß den Barrierefreiheitsstandards der WCAG 2.2 überprüft
• Übergabedatei im vereinbarten Tool mit allen Spezifikationen, Assets und Anmerkungen vorbereitet
• Freigabe der wichtigsten Stakeholder erhalten und dokumentiert
• Bausteine im Designsystem aktualisiert, falls neue Muster eingeführt wurden
• Responsives Verhalten über vereinbarte Breakpoints hinweg validiert

Definition of Done vs. Akzeptanzkriterien

Die Definition of Done ist der teamweite Qualitätsstandard, während Akzeptanzkriterien die funktionalen Anforderungen auf Feature-Ebene beschreiben.

Stellen Sie sich die Definition of Done als universelle Grundlage vor, während die Akzeptanzkriterien einzigartig für jedes Sprint-Backlog- oder Product-Backlog-Element sind. Ein Product-Backlog-Element gilt als abgeschlossen, wenn es sowohl seine Akzeptanzkriterien als auch die Team-Definition of Done erfüllt.

Häufige Fallstricke und Fehler

Hier sind einige typische Fehler, die Sie bei der Erstellung von Definitionen of Done vermeiden sollten:

• Punkte überspringen, um schneller zu werden: Teams unter Zeitdruck lassen häufig Kriterien wie Sicherheitsüberprüfungen, Barrierefreiheitstests oder Dokumentation weg. Dies erzeugt versteckte technische Schulden, die später als Bugs, Nacharbeiten oder Compliance-Probleme sichtbar werden.
• Die Checkliste zu detailliert machen: Eine zu umfangreiche Definition of Done wird zu einer bürokratischen Last. Wenn Ihre Checkliste 30 Punkte enthält und Entwickler mehr Zeit mit dem Abhaken als mit der Entwicklung verbringen, sind Sie zu weit gegangen. Seien Sie spezifisch genug, um sinnvoll zu sein, aber allgemein genug, um praktikabel zu bleiben.
• Die Definition of Done pro Story ändern: Der Sinn der Definition of Done liegt in ihrer Konsistenz. Funktionsspezifische Bedingungen gehören in die Akzeptanzkriterien (wie zum Beispiel Given-When-Then-Akzeptanzkriterien), nicht in die Definition of Done.
• Sie nie wieder betrachten: Eine Definition of Done sollte sich weiterentwickeln, wenn Ihre Arbeitsweisen reifen, sich Ihre Werkzeuge ändern oder Ihr Produkt wächst. Ich empfehle, sie mindestens einmal im Quartal in Retrospektiven zu überprüfen und bei festgestellten Lücken oder Reibungen anzupassen.
• Sie nicht durchsetzen: Eine Definition, die immer dann aufgehoben wird, wenn jemand Wichtiges darum bittet, ist wertlos. Die Aufgabe des Scrum Masters ist es, die Definition zu schützen – auch wenn ein Stakeholder etwas liefern will, das den Standard nicht erfüllt. Werden Kriterien regelmäßig außer Kraft gesetzt, verliert das Team das Vertrauen in den Standard und nimmt ihn nicht mehr ernst.
• „Done“ mit „deployt“ verwechseln: Die Definition of Done gibt vor, ob ein Inkrement auslieferbar ist, nicht, ob es ausgeliefert wurde. Ein Product-Backlog-Element kann fertiggestellt sein, ohne deployt zu sein. Fügen Sie „in Produktion deployt“ nur dann zur Definition of Done hinzu, wenn Ihr Team den gesamten Release-Prozess verantwortet.
• Sie nicht zu referenzieren: Viele Teams haben zwar formal eine Definition of Done, aber wenn sie niemand seit sechs Monaten angeschaut hat, funktioniert sie nicht als Qualitätsstandard.

Wie geht es weiter?

Stärken Sie Ihre agilen Prozesse und Arbeitsweisen mit praktischen Tools, Vorlagen und Expertenwissen über eine kostenlose DPM-Mitgliedschaft und verbessern Sie die Systeme, mit denen Teams kontinuierlich hochwertige Arbeit abliefern.