Definition of Done: Simpel und doch komplex

Die Definition of Done (DoD) ist ein wichtiges agiles Werkzeug, das Teams dabei hilft, Arbeit zu planen und durchzuführen. Im Prinzip ist die Definition of Done nur eine Reihe von Kriterien, die das Produkt erfüllen muss, um als fertig zu gelten. Doch obwohl das Konzept so einfach ist, ist die Umsetzung in Wirklichkeit nicht ganz so einfach. Der Kontext und die Interpretationsmöglichkeiten bilden nämlich eine Grauzone.

Kontext und Akzeptanzkriterien

Die erste Ebene an Komplexität besteht daraus, dass die Definition of Done immer im Kontext der Umgebung gesehen werden muss, was sich auf die technische sowie funktionelle Vollständigkeit und die Akzeptanz durch den Product Owner bezieht. Die Tatsache, dass der Product Owner das Produkt akzeptiert, steht stellvertretend für den Wert des Produkts. Akzeptanzkriterien – oder wie sie auch immer genannt werden mögen – spiegeln wider, ob der Code ein bestimmtes Geschäftsproblem lösen kann, das durch die User Story oder eine Anforderung definiert wurde. Akzeptanzkriterien sollen bestätigen, dass die Story wirklich das tut, wofür sie gedacht war, und sie können für die Erstellung von Akzeptanztests genutzt werden.

Formal betrachtet ist die Definition of Done häufig ein Spiegelbild der technischen und prozessbezogenen Standards einer Organisation. Beispielsweise haben Organisationen oft Standards für das Schreiben von Code und Unit Tests und daher kann die Definition of Done die Anforderungen für die Struktur des Codes, die Dokumentation und das Testen enthalten. Sie kann auch Komponenten beinhalten, die mit Funktionalität zu tun haben. Allerdings ist die Funktionalität grundsätzlich durch die Akzeptanzkriterien etc. in der Definition enthalten. In einigen Fällen habe ich schon Aussagen in der Definition of Done gesehen, die darauf hinweisen, dass die Akzeptanzkriterien eingehalten werden müssen. Nachdem die doppelte Hürde aus Definition of Done und Akzeptanzkriterien überwunden ist, muss der Product Owner die Bewertung des gelieferten Werts der Lösung abgeben. Danach erfolgt die finale Bewertung, bei der er die Lösung akzeptiert oder ablehnt. Das Ergebnis dieses Prozesses wird auch als done-done oder sogar done-done-done beschrieben.

Hürden und wichtige Fragen bei der DoD

Um das Konzept von „Done” auf solide Art und Weise umzusetzen, muss man drei Hürden überwinden: die Kriterien der Definition of Done, die Akzeptanzkriterien (als Teil einer User Story) und die Akzeptanz durch den Product Owner. Dazu gehört außerdem das Abwägen einiger Fragen, die den sonst relativ einfachen Prozess etwas schwieriger gestalten. Dazu gehören:

1. Wer entscheidet, was Done bedeutet?
   In vielen Organisationen werden die Done-Kriterien oft den einzelnen Teams überlassen. Das geschieht normalerweise innerhalb der Grenzen der technischen und prozessbezogenen Standards, die von der Organisation definiert wurden. Vor ein paar Jahren wurde ich beispielsweise von einem Entwicklungsteam mit strengen Standards zum Coding und den Unit Tests gefragt, ob sie die Unit-Test-Anforderungen für ihren Code weglassen dürften. Unit Tests waren ein Kriterium in ihrer Definition of Done. Ihre Begründung war, dass die Tester später im Prozess herausfinden würden, ob es funktioniert, und dass der Product Owner die Tests der Programmierer nicht möge. Allerdings musste sich das Team an die von der Organisation vorgegebenen Standards halten und es stand nicht zur Diskussion, die Anforderungen für die Unit Tests einfach wegzulassen.

2. Ist es akzeptabel, wenn die Kriterien nicht vollständig erfüllt werden?
   Jedes Team, mit dem ich jemals gearbeitet habe, hat sich früher oder später die Frage gestellt, ob es in Ordnung wäre, die Definition of Done anders auszulegen und so zu umgehen. Oft lautet die Antwort „Ja”. Das bedeutet allerdings meist eine Diskussion über die Grauzone, das Akzeptieren technischer Schulden und wann diese Schulden getilgt werden sollen.

3. Können die Bedürfnisse der Organisation wichtiger sein als die des Product Owners?
   Das ist das Alter Ego der vorherigen Frage. Jeder im Team, inklusive Product Owner, muss wissen, wann und wo die Standards und/oder Bedürfnisse der Organisation wichtiger sind als die Akzeptanz durch den Product Owner. Der Druck, etwas liefern zu müssen, kann Teams und Product Owner dazu verleiten, den Code voranzutreiben, um ihn dann in späteren Sprints zu überarbeiten, was die Standards und die Architektur an ihre Grenzen bringt. Die meisten reiferen Organisationen ziehen klare Grenzen, so dass jeder weiß, wann die Bedürfnisse und Standards der Organisation respektiert werden müssen.

Fazit zur Definition of Done (DoD)

Alle Definitionen des Wortes „Done” beinhalten ein gewisses Maß an Endgültigkeit und Vollständigkeit. Bei der Softwareentwicklung, -verbesserung und -wartung kann das Konzept von Done sehr vielschichtig sein. Jede dieser Schichten kann ihre eigenen technischen, funktionellen und wertbezogenen Nuancen haben. Teams lernen schnell, dass eine Arbeit wirklich done, done und done sein muss, um tatsächlich fertig zu sein.

Dieser Text stammt aus dem Blog von SPaMCAST und wurde von uns ins Deutsche übersetzt.