Die Äußerung „Das Bessere ist der Feind des Guten“ wird gemeinhin Voltaire zugeschrieben. Moderne Softwareentwicklungsteams verstehen, dass „echte Künstler liefern“ und Innovationen häufig in der Iteration entstehen. 

Agile Teams müssen wissen, wann ein Produkt oder ein Projekt „Done“ – also „fertig“ – ist, um endlose Iterationsschleifen zu vermeiden, die ein Projekt eher schwammig machen und verkomplizieren, als es zu verbessern. Ein Mangel an klaren Vorstellungen darüber, was „Done“ ist, kann zu lähmendem Perfektionismus führen –oder schlimmer noch, zu Apathie. 

Die „Definition of Done“ (DoD) ist eine Sammlung von Leistungen im Rahmen eines Projekts oder Vertrags, die nach Abschluss als überprüfbare und nachweisbare Benchmarks für ein Projekt dienen. Kurz: Es ist eine Liste von Leistungen und ein gemeinsames Verständnis von den Erwartungen an die Anforderungen, die ein Team erfüllen muss, bevor ein Produkt für Benutzer freigegeben wird. 

Da eine DoD bereits in der Frühphase eines Projekts festgelegt werden muss, gilt es, sie auch schon bei der anfänglichen Planung und beim Brainstorming zu einem Projekt zu berücksichtigen. Werfen wir also einen Blick darauf, wie die Definition of Done in Agile Projektmanagern und Teams dabei hilft, flexibel und produktiv zu bleiben und sich auf das Benutzererlebnis zu konzentrieren. Außerdem erläutern wir, wie Sie eine DoD einführen können.

Warum eine Definition of Done in Agile einsetzen? 

Erfahrung lehrt am besten –und das Benutzererlebnis ist der beste Indikator, um zu verstehen, ob Ihr Produkt den Bedürfnissen Ihrer Kunden entspricht. Dafür benötigen Sie natürlich ein bereits eingeführtes Produkt. 

Durch Einführung und Umsetzung einer DoD in Ihren Workflow kommen Sie schneller zu einem fertigen Produkt oder zumindest einem Minimum Viable Product. Von dieser Position aus können Sie dann das Feedback bekommen, das Sie brauchen, um bessere Produkte herzustellen, Planungsprozesse zu verbessern und zukünftige Projekte zu visualisieren und zu planen. Sehen wir uns die einzelnen Vorteile einmal genauer an.

Nützliches Feedback zur Verbesserung erhalten

Eine Definition of Done spiegelt die notwendigen Schritte wider, um die Schritte innerhalb eines Sprints einzuhalten. Scrum- und Agile-Teams bietet diese Benchmark die Möglichkeit, zu testen, zu iterieren, zu lernen und das Ergebnis des nächsten Sprints zu verbessern. In jedem Schritt der DoD-Checkliste ist Feedback möglich und gleichzeitig kann der Releaseplan auf Kurs gehalten werden. 

Planung verbessern

Wenn ein Projekt nie „Done“ ist, gibt es wahrscheinlich viele WIP-Schritte (Work in Progress), die künftige Sprints und Workflows überladen und durcheinanderbringen können. Unendliche Produktsprints führen oft zu überkomplizierten Problemen. Zwar sind Qualität und Funktionalität immer das Ziel, aber es ist überaus wertvoll, ein Minimum Viable Product zu lancieren und von den Interaktionen der Benutzer zu lernen. 

Definition of Done hilft Scrum- und Agile-Teams dabei, Produktauslieferungen wirklich in definierbare Schritte aufzuteilen, was eine bessere Planung der kommenden Sprints ermöglicht. Mit DoD können Entwicklungsteams liefern, testen, lernen, iterieren und wiederholen – und dabei stets die Zukunft im Blick behalten. 

Den Status von Projekten im Laufe der Zeit visualisieren

Neben einer verbesserten Planung hilft Ihnen die Definition of Done in Agile, den Fortschritt eines Projekts schnell zu visualisieren. So haben Sie jederzeit genau im Blick, was bereits getan wurde, was als Nächstes ansteht und wohin die Produktentwicklung geht. Diese Transparenz kann auch dazu beitragen, dass die Abstimmung im gesamten Unternehmen stimmt – wenn richtungsweisende Gespräche und Produktentwicklungsarbeiten in Silos stattfinden, dauert es nicht lange, bis strategische Wege auseinandergehen. 

Wie sieht eine DoD genau aus? Zahlreiche Ausprägungen sind möglich, die einzelnen Kontrollpunkte werden aber in der Regel in einer Produkt Roadmap oder auf einem Scrum Board dokumentiert. Beide geben eine klare Skizze und Visualisierung des Stands eines Produkt-Sprints. 

Mit der Zeit trägt eine DoD zur Schnelligkeit eines Teams bei, denn sie stellt sicher, dass Arbeiten nicht doppelt ausgeführt werden und dass der lieferfähige Zustand des Produkts oder der App-Umgebung den Anforderungen der User Story und den Erwartungen des Marktes entspricht. 

Der Qualität eines agilen Produkts entsprechen

Methoden für agile Workflows sind von Natur aus flexibel und zugleich ergebnisorientiert. Ausgereifte Scrum- und Agile-Teams leben diese flexible Arbeitsweise, sind aber auch auf gemeinsame Ziele ausgerichtet und engagiert, so schnell wie möglich das beste Produkt zu liefern. Eine DoD unterstützt und spiegelt diese Agilität. 

So ermitteln Sie Ihre DoD

Oben haben wir kurz die Risiken erwähnt, die Perfektionismus und Apathie bergen. Beide können daraus entstehen, dass keine DoD definiert wird. Und beide führen zu einer misslungenen Produkteinführung. Verschiedene Teams und Stakeholder können unterschiedliche Vorstellungen davon haben, was „Done“ bedeutet. Kollaboration und Kompromisse sind aber wichtig, um über die Abnahmekriterien für die einzelnen User Storys, Features und Issues einen Konsens zu erreichen. Jedes Teammitglied muss sich am Ende für diese Standards verantwortlich fühlen. Diese Anforderungen müssen klar, umsetzbar und jederzeit zugänglich sein.

Machen Sie Ihre Definition of Done zu einer Teamentscheidung

Die Gestaltung einer Definition of Done sollte eine funktionsübergreifende Zusammenarbeit zwischen Produktteams, Projektmanagern, der Qualitätskontrolle und relevanten Stakeholdern sein. Die Definition einer DoD hängt von den aktuellen Prioritäten hinsichtlich der Benutzer und dem Unternehmen ab, bedeutet im Allgemeinen aber, dass der entwickelte Code die Ziele von User Story, Features, Version oder Issues erfüllt und nicht dazu führt, dass ein früherer Sprint der Produktentwicklung nicht mehr funktioniert. 

Auf einer taktischeren, detaillierteren Ebene können DoD-Checklisten wie folgt aussehen:

• Code ist geschrieben
• Code ist dokumentiert
• Code ist geprüft
• Code oder Build wird in einer Testumgebung bereitgestellt 
• Code besteht Tests 

Neben traditionellen Visualisierungs- und agilen Projektmanagement-Tools wie Produkt Roadmaps und Scrum-Boards können Tools für die visuelle Zusammenarbeit wie Lucidspark auch sicherstellen, dass die DoD-Anforderungen für nicht-technische Teams transparent sind. Darüber hinaus haben damit alle Beteiligten Zugriff auf diese Anforderungen und es gibt eine klare Abstimmung darüber, was erforderlich ist, um ein Feature voranzubringen – und was als Nächstes kommt. 

Checkliste und spezifische Anforderungen zur Erfüllung der DoD erstellen (Abnahmekriterien)

Einfach ausgedrückt sind Abnahmekriterien die Benchmarks, die erforderlich sind, um Ihre DoD zu erfüllen. Wenn Sie eine Definition of Done eingeführt haben, ist es wichtig, eine Checkliste mit Regeln zu erstellen, die das große Ganze und den Kontext des aktuellen Sprints berücksichtigen. Außerdem müssen sie für jede Aufgabe innerhalb dieses Sprints gelten, egal ob es um ein völlig neues App-Erlebnis oder einen einfachen Bugfix geht. Das Wichtigste ist Einheitlichkeit. 

Unten sehen Sie eine einfache Checkliste für „Done“-Abnahmekriterien Hinweis: Diese Kriterien können sich im Laufe der Zeit ändern, wenn sich DoD- und Produktanforderungen sowie Prioritäten ändern.

• Einheitentest bestanden
• Code geprüft
• Abnahmekriterium für jedes Issue erfüllt
• Funktionstest bestanden
• Anforderungen erfüllt, die nicht die Funktionen betreffen
• Product Owner nimmt die User Story ab

Sind diese Punkte abgehakt, können Sie einen Sprint als „Done“ betrachten. Anschließend können Sie überprüfen, testen und Ihre Erkenntnisse anwenden, um neue Produktfeatures zu entwickeln, Fehler zu beheben, aktuelle Features zu iterieren und zu optimieren und den nächsten Sprint zu planen. Das Beste an einer DoD? Ihr Team entwickelt sich ständig weiter und lernt ständig dazu. 

Verantwortlichkeit an Aktionspunkte binden

Die Abstimmung von Abnahmekriterien ist entscheidend, damit sich jedes Teammitglied für jeden Schritt verantwortlich fühlt. Während des Sprint-Planungsprozesses sind einzelne Teammitglieder für verschiedene Schritte verantwortlich. Stellen Sie daher sicher, dass Ihre Abnahmekriterien und Checklisten neben der Arbeit immer sichtbar sind, um in jeder Phase des Entwicklungszyklus Transparenz und Verantwortlichkeit zu gewährleisten. 

Sicherstellen, dass die DoD zu den Unternehmensanforderungen und den vertraglichen Zielen passt

Damit Arbeitsschritte und Sprints nicht zu vergeudeter Zeit werden, ist es wichtig, Prioritäten und DoD gelegentlich mit den übergeordneten Unternehmenszielen abzugleichen. So können Sie sicherstellen, dass alles aufeinander abgestimmt ist und strategischen blinden Flecken vorbeugen. Eine erfolgreiche Produktauslieferung taugt letztlich nur so viel wie die Ziele, die sie erreicht. Eine sorgfältige Zusammenarbeit und Abstimmung mit den wichtigsten Stakeholdern und Product Ownern stellt sicher, dass jeder Produktsprint dem Unternehmen als Ganzes dient. 

Vielen qualitätsorientierten Produktentwicklungsteams mag es verlockend erscheinen, mit jedem Sprint und jeder App-Version Perfektion zu erreichen. Teams, die sich eine DoD zu eigen machen, können flexibler agieren, schneller mehr über ihre Benutzer herausfinden und letztendlich bessere Produkte entwickeln.