„Fertig“ kann bedeuten, dass Code geschrieben wurde, ein Pull Request offen ist oder eine Funktion produktiv abgenommen wurde. Ohne gemeinsame Definition entstehen Missverständnisse, die erst kurz vor dem Release sichtbar werden.
Gemeinsamer Qualitätsrahmen
Eine Definition of Done beschreibt Kriterien, die für alle passenden Aufgaben gelten. Dazu können Code Review, automatisierte Tests, erfolgreiche Builds, aktualisierte Dokumentation, Security-Prüfungen und fachliche Abnahme gehören. Sie ergänzt individuelle Akzeptanzkriterien, ersetzt sie aber nicht.
Der Rahmen sollte zum Risiko passen. Eine interne Textänderung braucht andere Nachweise als eine Zahlungsintegration oder Migration.
Verantwortung sichtbar machen
Für jedes Kriterium muss klar sein, wer es erfüllt oder bestätigt. Engineers können technische Tests liefern; die fachliche Abnahme braucht häufig eine verantwortliche Person beim Kunden. Fehlt diese Verfügbarkeit, stauen sich scheinbar fertige Aufgaben.
Im Arbeitsablauf verankern
Checklisten in Pull Requests, verpflichtende Build-Checks und eindeutige Ticket-Zustände machen die Definition im Alltag nutzbar. Ein Dokument, das niemand beim Review sieht, verändert keine Delivery.
Ausnahmen sollten bewusst entschieden und dokumentiert werden. Wenn ein Test wegen Zeitdruck fehlt, entsteht technische Schuld – keine unsichtbare Abkürzung.
Regelmäßig anpassen
Ein neuer Workstream beginnt häufig mit einem einfachen Rahmen. Nach ersten Releases wird sichtbar, welche Fehler wiederkehren oder welche Checks nur Overhead erzeugen. Die Definition darf sich weiterentwickeln, solange Änderungen transparent sind.
Übergabe einbeziehen
Externe Delivery ist erst belastbar, wenn Arbeitsergebnisse auch für andere verständlich bleiben. Relevante Entscheidungen, Betriebswissen und offene Risiken gehören deshalb in die Definition – besonders vor Rollenwechsel oder Projektende.