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.
