Eigentlich fast fertig? Die Definition of Done!

Es ist Freitag Vormittag, 09:00 Uhr; Zeit für unser Daily. Ein Kollege zeigt auf das Taskboard und sagt “Diese User Story ist eigentlich fertig und kann in unsere Done-Spalte gehängt werden”. Wörter, wie “eigentlich” oder “fast” machen mich stutzig und ich kann nicht anders als nachzufragen, ob die Definition of Done für diese User Story erfüllt ist. Mein Kollege verneint und ergänzt: “Es fehlt noch die Betriebs-Doku”. Ich mache meine Kollegen aufmerksam, dass alle Kriterien der Definition of Done erfüllt sein müssen, damit eine User Story in die Spalte Done geschoben werden kann und somit als abgeschlossen gilt.

Was ist die Definition of Done?

In Scrum definiert eine Liste von Fertigstellungsaktivitäten, auch Definition of Done genannt, was zu tun ist, damit eine User Story als abgeschlossen gilt. Tja, Qualität ist nicht variabel!

Wie sieht so eine Definition of Done aus?

Ein Beispiel für eine Definition of Done:

• Die Akzeptanzkriterien der User Story sind erfüllt
• Alle Unit Tests sind geschrieben und laufen grün
• Der Code ist im Repository erfolgreich eingecheckt
• Ein Code Review wurde durchgeführt
• Die Betriebs-Dokumentation wurde geschrieben
• Die User Story wurde vom PO abgenommen

Die Definition of Done ist eine Checkliste und diese sollte gut sichtbar in der Nähe des Taskboards vom Team aufgehängt werden.

Warum benötigt man eine Definition of Done?

Es gibt viele Gründe wozu ein Entwicklungsteam eine Definition of Done braucht. Meiner Ansicht nach die wichtigsten Drei sind:

1. Alt-Lasten vermeiden und Fokus: Das Entwicklungsteam soll sich auf die User Stories des aktuellen Sprint Backlogs konzentrieren und nicht an den vermeintlich abgeschlossenen User Stories vom letzten Sprint arbeiten.
2. Ein gemeinsames Verständnis von Qualität: Jeder sieht Qualität anders. Eine Liste von Fertigstellungsaktivitäten helfen ein gemeinsames Verständnis dafür zu erlangen.
3. Zur Sicherstellung eines potentiell lieferbaren Produkt-Inkrement: am Ende eines Sprints soll ein potentiell lieferbares Produkt-Inkrement entstehen. Wenn der PO das GO zum Deployen der User Story gibt, dann sollte dies auch unmittelbar möglich sein – ohne ein “aber wir müssen noch … tun“.

Wie kommt man zur Definition of Done?

Wenn ihre Entwicklungsteams noch keine Definition of Done erarbeitet haben, dann empfehlen wir einen Workshop, an welchem die Entwicklungsteams, POs und Stakeholder, wie zum Beispiel Kollegen aus dem IT-Betrieb, teilnehmen.

Der Ablauf des Workshops gestaltet sich folgendermaßen:

1. Einführung: Der Moderator holt die Teilnehmer ab und erklärt den Zweck der Definition of Done und das Ziel des Workshops.
2. Die Fertigstellungsaktivitäten in Entwicklungsteams erarbeiten: Die einzelnen Teams halten auf Post It & Flipcharts fest, was alles zu tun ist, damit eine User Story aus ihrer Sicht abgeschlossen ist – unabhängig davon ob das Team, diese Aktivitäten aktuell auch schafft. Als Format kann hier Brainstorming oder Brainwriting verwenden werden.
3. Die Ergebnisse der Entwicklungsteams vergleichen und ergänzen: Die Teams vergleichen die Fertigstellungsaktivitäten und gleichen diese gegebenenfalls an. Eventuell hat ein Team eine wichtige Aktivität übersehen. Es soll eine Art Basis geschaffen werden, welche für alle Teams gültig ist. Des Weiteren bekommen die einzelnen Entwicklungsteams ein Bewusstsein, was andere Teams als Qualität von abgeschlossener Arbeit verstehen.
4. Die Definition of Done in Teams festlegen: Von den festgehaltenen Fertigstellungsaktivitäten werden nun jene gewählt, welche das Entwicklungsteam auch tatsächlich schafft. Die Aktivitäten, die das Team noch nicht schafft, wie zum Beispiel die Test-Automatisierung, werden in einer Definition of Done 2.0 festgehalten. Diese Definition of Done 2.0 soll als Ansporn für die Zukunft gelten.

Wie die Definition of Done 2.0 schon andeutet, ist die Definition of Done ein lebendes Artefakt. Dieses Artefakt soll kontinuierlich angepasst werden, zum Beispiel in der Retrospektive, so dass die Qualität der abgeschlossenen User Stories erhöht wird.

Möchten Sie mehr über diese Themen erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Trainings, wie beispielsweise das zum  Certified Agile Requirements Specialist (CARS), zum Scrum Master,  der Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung, CPRE Advanced Level es ist bestimmt etwas für Sie dabei! Das gemeinsame Erarbeiten der Definition of Done ist nur eines von vielen unserer Dienstleistungen, die wir für Sie anbieten.

Dominik Angerer

Kontaktieren Sie Dominik Angerer

Dominik Angerer arbeitet bei Agile-by-HOOD als Consultant und betreut mit Leidenschaft und viel persönlichem Engagement Menschen, Teams und Organisationen bei der Anwendung und Umsetzung von agilen Prinzipien. Er hat eine fundierte Ausbildung in Informatik und hat seine Social Skills in mehreren Auslandsaufenthalten weiterentwickelt. Sein theoretisches Wissen hat er bei diversen Praktika eingesetzt und somit Erfahrungen in SW-Entwicklung, Projekt-Management und Requirement-Engineering gesammelt.