Eine Definition-of-Done-Checkliste, die auf dem Arbeitselement bleibt

Was ist eine Definition-of-Done-Checkliste?

Definition of Done ist die Qualitätsleiste, die jede Story nehmen sollte, bevor jemand sie nach Done schiebt. In Jira macht eine Checkliste daraus abhakbare Schritte auf dem Arbeitselement selbst: Peer Review erledigt, CI grün, Docs aktualisiert. Die Liste ist für jede Story gleich; nur die Haken ändern sich.

Eine Definition-of-Done-Checkliste schafft Klarheit und nimmt Mehrdeutigkeit, bevor jemand Arbeit nach Done schiebt. Statt zu fragen „Ist es schon fertig?“, „Haben wir dieselben Standards wie letztes Mal?“ oder „Was ist unsere Qualitätsleiste für diese Story?“ zeigt das Team auf die Liste am Vorgang. Alle sehen dieselben Schritte, haken dieselbe Evidenz ab und einigen sich, was „fertig“ heißt.

Die Lücke zeigt sich in der Alltagssprache. Ein Team sagt, eine Story ist done, wenn Entwicklung, Tests und Code Review fertig sind — heißt das deployed? Ein anderes Team meint done erst, wenn die Änderung den gesamten Delivery-Zyklus durchlaufen hat und in Produktion live ist. Eine Definition-of-Done-Checkliste erzwingt dieses Gespräch einmal, schreibt die Antwort auf den Vorgang und verhindert, dass jede Story dieselbe Debatte neu aufmacht.

Warum Teams Definition of Done auf dem Vorgang halten

Die meisten Teams wissen, wie „gut“ aussieht. Die Reibung ist das Wiederholen. Ohne gemeinsame Liste wird „done“ zur Debatte im Stand-up, Review-Kommentare leben an drei Stellen, und die nächste Person erbt eine unvollständige Übergabe. Eine Checkliste auf dem Vorgang macht die Leiste explizit: alle sehen dieselben Schritte, Fortschritt ist auf dem Board sichtbar, und nichts Kritisches versteckt sich in einem Kopf.

In der Software Delivery zahlt sich das auf jeder Story aus: Sie öffnen das Ticket, sehen, was offen ist — Review gemerged, Tests grün, Docs aktualisiert — haken ab und gehen erst nach Done, wenn die Evidenz auf dem Vorgang liegt. Dieselbe Leiste gilt, ob Sie ein Feature ausliefern, einen Bug beheben oder Tech Debt aufräumen.

Wann Sie sie anwenden

Nutzen Sie eine Definition-of-Done-Checkliste auf jeder Story, jedem Bugfix oder Task, der dieselbe Qualität hinterlassen soll. Wenden Sie sie an, wenn Arbeit nach In Progress wechselt oder wenn die Story erstellt wird, damit die Leiste von Anfang an da ist. Verlangen Sie sie vor dem Done-Übergang, wenn Done heißen soll, dass die Leiste erfüllt ist.

Definition of Done vs. Acceptance Criteria vs. Ready

Acceptance Criteria beschreiben das versprochene Verhalten dieses Arbeitselements — die Beispiele, die Sie demoen. Definition of Ready fragt, ob das Element klar genug ist, um in den Sprint gezogen zu werden. Definition of Done ist die gemeinsame Exit-Leiste: Tests, Review, Dokumentation und Release-Bereitschaft, die jede Story der nächsten Person schuldet. Teams, die alle drei als Checklisten auf dem Vorgang halten, sehen den Unterschied, statt im Stand-up darüber zu streiten.

Definition of Done — ein Beispiel zum Start

Wenn Sie noch keine Definition-of-Done-Checkliste haben, starten Sie mit dem Beispiel unten. Kopieren Sie die Liste und fügen Sie sie in das Eingabefeld von Checklist for Jira auf einem Arbeitselement ein. Ideal: als Vorlage speichern und auf jede Story anwenden — das spart manuelle Arbeit, jedes Mal wenn jemand ein Ticket startet. Passen Sie die Überschriften an Ihren Stack an; halten Sie die Liste auf dem Arbeitselement, damit Fortschritt sichtbar bleibt.

Speichern, schützen, automatisieren, verlangen

Machen Sie aus dem Beispiel einen Standard, den Ihr Team auf jeder Story, jedem Task und jedem Bug fährt. Vier Schritte in Checklist for Jira: Vorlage speichern, Struktur schützen, mit Built-in-Automatisierung automatisch anwenden, dann Vollständigkeit vor Done verlangen.

Speichern

Legen Sie eine Projektvorlage in den Checklist settings des Projekts an oder eine globale Vorlage in der Jira-Administration und fügen Sie die Liste aus dem Beispiel ein. Passen Sie die Punkte an Ihren Stack an und ergänzen Sie eine kurze Beschreibung, damit Teammitglieder — und der Rovo-Agent — wissen, wann sie greift. Eine gespeicherte Vorlage ist der Weg, dieselbe Definition of Done auf jeder Story wiederzuverwenden, ohne sie neu einzugeben, und sie schaltet Auto-Apply und Workflow-Validatoren in den nächsten Schritten frei.

Schützen

Markieren Sie die Vorlage im Tab Advanced als Protected. Menschen können Punkte abhaken und Item-Status auf dem Vorgang ändern, während die Schrittliste gesperrt bleibt — Definition of Done bleibt auf jedem Arbeitselement, das die Vorlage berührt, gleich.

Automatisieren

Nutzen Sie die eingebaute Automatisierung pro Vorlage, um diese Definition of Done anzuhängen, wenn gewählte Vorgangstypen erstellt werden oder Arbeit in einen Status wechselt, den Sie wählen. Haken Sie Story, Task und Bug an (oder welche Typen dieselbe Leiste tragen sollen), damit die Liste auf dem Vorgang ist, bevor jemand abhakt. Die gute Nachricht: Diese Automatisierungen stecken in Checklist for Jira und laufen ohne Jira-Automation-Credits.

Verlangen

Fügen Sie einen Completion-Validator auf dem Done-Übergang in Ihrem Jira-Workflow hinzu. Begrenzen Sie ihn auf diese Vorlage aus der Vorlagenliste, damit der Übergang wartet, bis jeder Punkt vollständig ist — das Arbeitselement bleibt offen, bis die Checkliste fertig ist. Der Automatisierungsleitfaden führt Validatoren, Post Functions und härtere projektübergreifende Regeln durch.

Mit dem Rest des Delivery-Sets kombinieren

Halten Sie Acceptance Criteria auf demselben Vorgang für das Beispiel. Hängen Sie die QA-Testcheckliste an, wenn der Vorgangstyp Bug ist oder QA einen eigenen Durchlauf besitzt. Nutzen Sie die Release-Checkliste auf der Änderung, die tatsächlich ausgeliefert wird. Das volle Set finden Sie im Vorlagen-Hub.

Häufige Fragen