Definition of Done Nachlese - Interview mit Marc Bless

Worum es geht

Versteht mich nicht falsch – die meisten Teams wissen theoretisch, was eine Definition of Done ist. Was ich konsistent beobachte, ist jedoch ein riesiges Problem in der Praxis: Unter dem Druck der Sprint-Taktung und ohne einen wirklich klaren, gemeinsamen Qualitätsstandard entstehen Ergebnisse, die eigentlich noch nicht lieferfertig sind. Das führt zu inkonsistenten Releases, technischer Schuld und frustrierten Stakeholdern.

Das Problem ist nur: Oft herrscht im Team selbst Einigkeit darüber, was "fertig" eigentlich bedeutet. Jeder hat eine implizite Vorstellung, aber die wird nicht ausgesprochen. Kommt dir das bekannt vor? Ein Feature ist "eigentlich fertig", es fehlt nur noch die Dokumentation, ein kleiner Test oder die Performance-Optimierung. Am Ende des Sprints steht dann der berühmte "tanzende Bob" – die Illusion von Fertigstellung, die in Wirklichkeit noch viel Arbeit verbirgt.

In dieser Episode spreche ich mit Marc Bless darüber, warum eine klare, sichtbare und gemeinsam entwickelte Definition of Done dein wichtigstes Werkzeug gegen dieses Problem ist und wie du sie in deinem Team konkret umsetzt.

Für wen?

Episoden-Insights

Die DoD ist der globale Qualitätsrahmen – Akzeptanzkriterien sind item-spezifisch

Ein häufiger Missstand ist die Vermischung von Definition of Done und Akzeptanzkriterien. Das führt zu Unschärfe. Die DoD definiert die immer geltenden Mindestanforderungen an jedes Product Increment, das ihr ausliefert. Sie betrifft die gesamte Entwicklungs- und Umsetzungsqualität. Akzeptanzkriterien hingegen beschreiben die funktionalen Anforderungen eines einzelnen Features. Lasst uns mal gemeinsam abgleichen: Die DoD ist wie die Hygiene-Checkliste in einer Restaurantküche (immer gültig). Die Akzeptanzkriterien sind das Rezept für ein bestimmtes Gericht.

"Wir müssen diesen Qualitätsbegriff definieren... letztlich unsere Entwicklungs- und Umsetzungsqualität."

Starte einfach und entwickelt die DoD gemeinsam weiter

Der Anspruch, von Sprint 1 an die perfekte, allumfassende DoD zu haben, lähmt Teams. Der pragmatischere Weg ist, mit einer minimalen, aber verbindlichen Version zu beginnen. Das kann zunächst nur "Code ist getestet und eingecheckt" sein. Wichtig ist, dass das Team sie gemeinsam erarbeitet und sich dazu verpflichtet. Im Laufe der Zeit und durch regelmäßige Reflexion in der Retrospective wird diese Liste dann stetig erweitert und verfeinert – basierend auf euren realen Erfahrungen und Schmerzpunkten.

"Mit der maximal simplen Definition of Done am Anfang... um dann im Lauf der Zeit die Dinge implizit werden zu lassen."

Sichtbarkeit schafft Verbindlichkeit und dient als Arbeitshilfe

Eine DoD, die irgendwo in einem Wiki vergraben ist, ist wertlos. Sie muss im täglichen Arbeitskontext präsent sein. Hängt sie groß und sichtbar neben eurem Taskboard oder eurem digitalen Board an. Diese ständige visuelle Präsenz erinnert nicht nur an den Standard, sondern verwandelt die DoD in eine praktische Checkliste für jedes einzelne Arbeitselement. Sie ermöglicht dem Team, sich bei jedem Item die entscheidende Frage zu stellen: "Erfüllt dies wirklich alle Punkte unserer DoD, oder tricksen wir uns selbst aus?"

"Macht sie sichtbar neben dem Taskboard... dass ihr euch fragen könnt: Was fehlt uns noch, um die Sachen wirklich dann abzuliefern?"

Dein nächster Schritt

Du willst mit deinem Team direkt loslegen und eine erste, funktionierende Definition of Done erarbeiten? Unser Kompakt-Guide führt dich und dein Team in 3 konkreten Schritten durch den Prozess – von der Problemidentifikation bis zur verbindlichen Vereinbarung.