Angesichts der Bedeutung einer praktikablen Definition of Done für den Erfolg eines Scrum-Teams hat es mich immer wieder verwundert, wie nachlässig oder unwissend viele Scrum-Teams in Bezug auf ihre Definition of Done sind. Lassen Sie mich daher erste Prinzipien dieses kritischen Scrum-Erfolgsfaktors mit Ihnen diskutieren, die Ihnen helfen werden, die Effektivität, den Teamgeist und die Reputation Ihres Scrum Teams zu verbessern.
Der Zweck der Definition of Done gemäß dem Scrum Guide
Der Scrum Guide beschreibt die Definition von Done wie folgt:
“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
“The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”
“If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.”
“The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”
Im Scrum Guide wird die Definition of Done häufig erwähnt, um die Bedeutung eines weithin bekannten und akzeptierten Qualitätsstandards für ein erfolgreiches Scrum-Team und eine erfolgreiche Organisation zu unterstreichen. Ohne technische Exzellenz und hohe Produktqualität ist keine geschäftliche Agilität zu erreichen, neudeutsch: Business Agility, und beides wird durch die Definition of Done reflektiert und unterstützt.
Bitte beachten Sie bei den folgenden Zitaten aus dem Scrum Guide, dass sich die Nummer am Anfang der Abschnitte auf die Seite in der englischen PDF-Version des offiziellen Scrum Guide bezieht:
Page 5: However, the Developers are always accountable for instilling quality by adhering to a Definition of Done.
Page 6: The Scrum Master serves the Scrum Team in several ways, including helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
Page 7: During the Sprint, quality does not decrease.
Page 8: [Sprint Planning: What can be Done this Sprint?] Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
Page 8: [Sprint Planning: How will the chosen work get done?] For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.
Page 10: The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
Page 10: [Artifact commitment:] For the Increment it is the Definition of Done.
Page 10: Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
Page 12: Work cannot be considered part of an Increment unless it meets the Definition of Done.
Page 12: The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Page 12: The moment a Product Backlog item meets the Definition of Done, an Increment is born.
Page 12: The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
Page 12: If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.
Page 12: Instead, [an undone Product Backlog item] returns to the Product Backlog for future consideration.
Page 12: If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.
Page 12: If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
Page 12: The Developers are required to conform to the Definition of Done.
Page 12: If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
Meine zehn wichtigsten Definition of Done-Erfolgsprinzipien sind die folgenden:
Es gibt eine Definition of Done: Das sollte eine Selbstverständlichkeit sein: Ohne einen Qualitätsstandard, der definiert, was unter Releasefähigkeit zu verstehen ist, wird Ihr Scrum-Team mit einer langsamen, aber stetigen Verschlechterung seiner technischen Grundlagen konfrontiert sein und unweigerlich technische Schulden anhäufen. Wenn das strategische Ziel Ihres Unternehmens darin besteht, eine agile Organisation zu werden und Business Agility zu erreichen, haben Sie in diesem Stadium bereits verloren. Geschäftliche Agilität erfordert technische Exzellenz, und die Definition of Done ist unerlässlich, um dieses Niveau zu erreichen und zu halten.
Done bedeutet releasefähig: Der Zustand „done“, wie er in der Definition of Done definiert ist, bedeutet, dass wir unseren Kunden Produkt-Inkremente liefern können, ohne dass dies rechtliche, finanzielle oder ethische Konsequenzen nach sich zieht. Sobald ein Element des Produkt-Backlogs die Definition of Done erfüllt, ist keine weitere Form der Genehmigung erforderlich, weder durch den Product Owner noch durch ein „Quality Gate“, um ein Inkrement veröffentlichen zu können.
Passen Sie die Definition of Done der Organisation an die Bedürfnisse Ihres Scrum-Teams an: Wenn das Unternehmen eine Standard-Definition of Done vorgibt, betrachten Sie diese als den kleinsten gemeinsamen Nenner in Sachen Qualität. Passen Sie diese Definition of Done dann jedoch an die Bedürfnisse Ihrer Kunden oder Ihres Scrum-Teams an.
Transparenz: Die Definition of Done kann ihr Potenzial als universeller Qualitätsstandard nur dann voll ausschöpfen, wenn jeder in der Organisation Zugang zu ihr hat und sie versteht. Wenn Sie die Definition of Done verstecken, kann sie außerhalb des Scrum-Teams nicht funktionieren. Eine ausgezeichnete Möglichkeit, die Definition of Done transparent zu machen, besteht darin, Ihre Stakeholder in ihre Erstellung einzubeziehen; siehe das nachfolgende Prinzip.
Machen Sie die Erstellung oder Anpassung der Definition of Done zu einer gemeinschaftlichen Anstrengung: Entgegen der landläufigen Meinung ist es nicht die Aufgabe der Entwickler, eine Definition of Done zu erstellen, sondern eine Aufgabe des gesamten Scrum-Teams. Wenn dies nun geklärt ist, warum erweitern Sie die Gruppe nicht zusätzlich, indem Sie Stakeholder und Fachexperten dazu einladen? Führen Sie z. B. Übungen durch, um zu erfahren, was Ihre Stakeholder unter „Done“ und Qualität verstehen. Natürlich liegt es immer noch in der Verantwortung des Scrum-Teams, seine Definition of Done festzulegen. Dennoch wird die Einbeziehung anderer in den Prozess dazu beitragen, Vertrauen aufzubauen.
Regelmäßige Überprüfung und Anpassung der Definition of Done: Ihre Definition of Done ist nicht statisch, sondern entwickelt sich weiter. Wenn das Scrum-Team mehr über das Problem und den Lösungsraum erfährt, wird es sich weiterentwickeln und bisher benachbarte Bereiche seiner Definition of Done übernehmen wollen, um Abhängigkeiten zu verringern und sein Selbstmanagement zu verbessern. (Bitte beachten Sie, dass eine solche Ausweitung der Verantwortlichkeit Vertrauen unter den Beteiligten voraussetzt. Ihr Scrum-Team kann sich nicht einfach in diese Position hineindrängen.) Eine effektive Methode, um herauszufinden, ob Ihre Definition of Done ein Upgrade benötigt, ist die regelmäßige Durchführung anonymer Umfragen unter Teammitgliedern und Stakeholdern.
Preisen Sie Ihre Definition of Done an: Sie müssen dem Rest der Organisation die Idee eines selbstverwalteten Qualitätsstandards schmackhaft machen. Die Definition of Done zu vermitteln ist vor allem dann notwendig, wenn die Organisation ansonsten an Q&A-Abteilungen, Quality Gates oder „Härtungssprints“ glaubt. Eine bewährte Methode, dies zu tun, besteht darin, Ihre Stakeholder einzuladen, sich an der Erstellung der Definition of Done Ihres Scrum-Teams zu beteiligen.
“Gut genug” reicht als Definition of Done aus: Bei der Definition of Done geht es nicht darum, das maximale Qualitätsniveau aus der verfügbaren Technologie herauszuquetschen. Das Qualitätsniveau Ihres Teams muss den Erwartungen der Kunden, den Anforderungen der Unternehmensführung und den allgemeinen ethischen und rechtlichen Standards entsprechen. Es gibt keinen Grund, alles, was Sie bauen, zu vergolden.
Zeigen oder liefern Sie keine unerledigten Arbeiten: Wenn Done gleichbedeutend mit release-fähig ist, dann ignorieren wir beim Sprint Review alles, woran wir arbeiten, bis es diese Stufe erreicht hat. Das ist ein grundlegendes Prinzip, das für die große Mehrheit aller Arbeiten gilt. Bis es das nicht mehr tut, z. B. im Notfall: Stellen Sie sich einen äußerst kritischen Fehler vor, der sofort behoben werden muss; eine improvisierte Zwischenlösung könnte in Ordnung sein, bis Sie kurz darauf mit der echten Lösung aufwarten können. Oder denken Sie an den kritischen Meilenstein, den ein Start-up mit knappen Kassen für die nächste Finanzierungsrunde unbedingt erreichen muss; wer will schon in Schönheit sterben? Das verbindende Element in diesen Beispielen ist jedoch dasselbe: Sie liefern jetzt eine minderwertige Version, um die Flut einzudämmen, und dann die echte, die „Done“ Version, so schnell wie möglich.
Geben Sie niemals die Definition of Done auf: In Scrum gibt es kein absichtliches Ignorieren der Definition of Done, zum Beispiel, um eine willkürliche Abgabefrist einzuhalten. Wenn Ihre Stakeholder jedoch Liefertermine aus dem Hut zaubern, müssen Sie sich mit diesem Anti-Muster der Zusammenarbeit innerhalb der Organisation auseinandersetzen. Irgendwie scheinen sie Ihrem Scrum-Team nicht zu vertrauen. Finden Sie heraus, warum das so ist, und beheben Sie das zugrunde liegende Problem, anstatt die Definition of Done Ihres Teams zu verletzen, um „die Dinge zum Laufen zu bringen“.
Definition of Done — Fazit
Die Definition of Done ist ein wichtiges Hilfsmittel für das Scrum-Team, um ein Inkrement in der erwarteten Qualität zu liefern. Sie bietet aus der Sicht des Teams eine gute Rendite und sollte das Scrum-Team zur Erreichung der Produktziele führen. Die Vernachlässigung der Definition of Done wird andererseits langsam, aber sicher die Fähigkeit des Teams, die Probleme der Kunden zu lösen, seinen Ruf und seinen Beitrag zur Nachhaltigkeit des Unternehmens untergraben.
Wie gehen Sie mit der Definition of Done um? Bitte teilen Sie Ihre Erfahrungen in den Kommentaren mit uns.
Professional Scrum-Schulungen nach Scrum.org, Workshops und Events
Lernen Sie, wie Sie die Definition of Done meistern können! Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:
Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.
✋ Nicht versäumen: Lernen Sie mehr über die Definition of Done im 12.000-köpfigen „Hands-on Agile Slack Team“
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Unterstützen Sie Ihr Scrum-Team bei der Erstellung einer hochwertigen Definition of Done, indem Sie gängige Anti-Patterns vermeiden. Laden Sie den kostenlosen Scrum Anti-Patterns Guide herunter:
Teile deine Liebe
Stefan Wolpers
Stefan ist Professional Scrum Trainer (PST) bei Scrum.org und arbeitet seit über 17 Jahren als Scrum Master, Agile Coach und Product Owner.
Stefan kuratiert den größten Newsletter der agilen Community — Food for Agile Thought — mit über 47.000 Abonnenten und ist der Admin der Hands-on Agile Slack-Community mit über 12.000 Mitgliedern.
