Definition of Done in Jira: Gemeinsam festlegen, was „fertig“ bedeutet

Ein Entwickler schließt eine Änderung ab und verschiebt den Jira-Vorgang weiter. Eine Testerin stellt fest, dass die neue Seite funktioniert, aber ein vorhandener Ablauf kaputt ist. Der Kundensupport erfährt durch einen verwirrten Kunden von der Änderung. Alle haben „fertig“ gesagt, aber etwas anderes gemeint.

Eine Definition of Done gibt dem Team einen gemeinsamen Fertigstellungsstandard. Sie macht die erwarteten Qualitätsprüfungen vor Arbeitsbeginn sichtbar, damit die Prüfung weniger davon abhängt, wer sich an die richtige Frage erinnert.

In dieser Anleitung entwickeln wir ein Beispiel für ein fiktives Kundenportal-Team, unterscheiden gemeinsame Qualitätsprüfungen von funktionsspezifischen Akzeptanzkriterien und halten beides mit dem Power-Pack-Werkzeug Definition of Done & AC bei einem Jira-Vorgang fest.

Was ist eine Definition of Done?

Der Scrum Guide beschreibt die Definition of Done als Qualitätsstandard, den ein Inkrement erfüllen muss. Sie schafft ein gemeinsames Verständnis abgeschlossener Arbeit. Hat eine Organisation einen Standard festgelegt, bildet dieser die Mindestanforderung für ihre Scrum-Teams. Siehe den offiziellen Scrum Guide.

Für unser Praxisbeispiel ist sie eine kleine Menge von Fragen, die das Team bei jeder relevanten Änderung stellt. Wurde die Umsetzung geprüft? Sind die vereinbarten Prüfungen bestanden? Stehen die Informationen bereit, die zur Unterstützung der Änderung benötigt werden?

Die konkreten Fragen hängen vom Produkt und seinen Risiken ab. Ein öffentliches Kundenportal, ein interner Bericht und ein sicherheitskritisches System benötigen unterschiedliche Standards. Die ungeprüfte Übernahme einer fremden Checkliste kann wichtige Lücken lassen und zugleich nutzlose Arbeit erzeugen.

Ein hilfreicher Standard beschreibt ein beobachtbares Ergebnis. „Hohe Qualität“ formuliert ein Ziel. „Die vereinbarten Regressionstests sind bestanden und ihre Ergebnisse im Jira-Vorgang verlinkt“ beschreibt etwas, das geprüft werden kann.

Trennen Sie gemeinsame Qualität vom Funktionsverhalten

Unser fiktives Team ergänzt Benachrichtigungseinstellungen. Kunden können eine wöchentliche Zusammenfassungs-E-Mail ein- oder ausschalten. Wichtige Kontonachrichten fallen nicht unter diese Einstellung.

Die Funktion braucht eigene Akzeptanzkriterien. Beispielsweise muss eine gespeicherte Auswahl nach Abmeldung und erneuter Anmeldung weiterhin angezeigt werden. Diese Anforderung gehört zur Funktion, weil sie das Kundenerlebnis beschreibt.

Die Definition of Done umfasst den übergreifenden Fertigstellungsstandard. Die Umsetzungsprüfung, die Prüfung betroffenen Bestandsverhaltens und aktualisierte Support-Hinweise können für viele Änderungen gelten.

Beide Listen sind wichtig. Eine Funktion kann wie gewünscht arbeiten, obwohl wesentliche Qualitätsarbeit fehlt. Umgekehrt belegen geprüfter Code und bestandene Regressionstests noch nicht, dass die angeforderte Funktion korrekt arbeitet.

Beginnen Sie mit tatsächlichen Lücken Ihres Teams

Bringen Sie die Personen, die das Produkt entwickeln, prüfen und unterstützen, zu einem kurzen Gespräch zusammen. Nutzen Sie ein aktuelles Beispiel für scheinbar abgeschlossene Arbeit, die unerwartete Nacharbeit benötigte.

Unser Portal-Team erkennt drei wiederkehrende Probleme. Prüfkommentare bleiben gelegentlich offen. Vorhandene Kontoeinstellungen werden nur wenig auf Regressionen geprüft. Support-Anleitungen kommen erst nach Bereitstellung der Funktion.

Diese Probleme legen hilfreiche Prüfungen nahe. Sie begründen auch, warum der Standard kurz bleiben sollte: Jeder Eintrag soll einen erkennbaren Fehler verhindern oder eine notwendige Qualitätsbedingung bestätigen.

Fragen Sie, wie jeder vorgeschlagene Eintrag geprüft werden kann. Kann niemand die Belege beschreiben, verbessern Sie die Formulierung vor der Übernahme. „Dokumentation vollständig“ könnte Versionshinweise, interne Entwurfsnotizen oder einen Hilfeartikel meinen. Vereinbaren Sie, welche Informationen benötigt werden und wohin sie gehören.

Vereinbaren Sie auch, wer die Prüfungen üblicherweise durchführt. Das kann in Ihrer normalen Planung geschehen. Eine Checkliste allein weist niemandem eine Prüfung zu und reserviert keine Kalenderzeit.

Entwerfen Sie eine praktische gemeinsame Checkliste

Hier ist der erste Entwurf des Portal-Teams. Er ist eine beispielhafte Arbeitsvereinbarung, kein universeller Standard.

• Die Umsetzungsprüfung ist abgeschlossen und erforderliche Prüfkommentare sind geklärt.
• Die vereinbarten Akzeptanzkriterien des Vorgangs sind geprüft.
• Die vereinbarten Regressionstests für betroffene Kontoabläufe sind bestanden.
• Die vereinbarten Barrierefreiheitsprüfungen für geänderte Seiten sind bestanden.
• Die Support-Hinweise entsprechen dem geänderten Kundenverhalten.
• Prüfergebnisse und relevante Prüfverweise sind im Jira-Vorgang festgehalten.

Vor der Verwendung schreibt das Team auf, was seine Regressions- und Barrierefreiheitsprüfungen umfassen. Andernfalls könnten zwei Personen denselben Satz nach unterschiedlicher Arbeit abhaken.

Für das Portal umfassen die vereinbarten Regressionstests die Anmeldung, das Öffnen der Kontoeinstellungen und die Änderung eines vorhandenen Profilfelds. Die Barrierefreiheitsprüfung geänderter Steuerelemente umfasst Tastaturbedienung, sichtbaren Fokus und verständliche Beschriftungen. Das sind Beispiele der gewählten Teamprüfungen, kein vollständiger Barrierefreiheitsstandard.

Auch der Support-Eintrag braucht eine praktische Auslegung. Hat eine Änderung keine Auswirkungen auf Kunden, sollte das Team vorab einen passenden Standard für solche Arbeit festlegen. Prüfende sollten keine Ausnahmen improvisieren müssen, nur um eine Liste grün zu bekommen.

Fügen Sie den Standard einem Jira-Vorgang hinzu

Öffnen Sie den passenden Jira-Vorgang und suchen Sie die Power-Pack-Karte Definition of Done & AC. Sie enthält die getrennten Registerkarten Acceptance Criteria und Definition of Done. Wählen Sie Definition of Done, bevor Sie die gemeinsamen Prüfungen hinzufügen.

Bei einer kleinen Liste geben Sie den Titel einer Prüfung ein und wählen Add oder drücken die Eingabetaste. Beschränken Sie jeden Titel auf eine überprüfbare Bedingung. Ein langer Satz mit drei unabhängigen Prüfungen erschwert das Abbilden eines Teilabschlusses.

Sie können auch Bulk Import wählen und eine Markdown-Liste einfügen. Kopieren Sie beispielsweise die sechs obigen Punkte mit einem Bindestrich und Leerzeichen am Zeilenanfang. Gewöhnliche Markdown-Kontrollkästchen werden ebenfalls unterstützt.

Der Import fügt Einträge zur ausgewählten Registerkarte hinzu. Prüfen Sie die Registerkarte vor dem Bestätigen und die entstandene Liste anschließend. Ein erneuter Import desselben Inhalts kann vorhandene Einträge doppelt hinzufügen. Nutzen Sie ihn deshalb gezielt, nicht als Aktualisierungsaktion.

Verwenden Sie nicht markierte Einträge für noch ungeprüfte Arbeit. Markierte Markdown-Kontrollkästchen werden als erledigt importiert. Aus einem früheren Vorgang kopierte Häkchen ersetzen keine Prüfung der aktuellen Änderung.

Der vereinbarte Standard muss manuell in jeden relevanten Vorgang übernommen werden. Halten Sie eine Referenzkopie in Ihrer üblichen Teamdokumentation und fügen Sie passende Prüfungen in neue Vorgänge ein. Dies ist eine Teampraxis, keine automatische Verbindung zwischen einem zentralen Standard und sämtlichen Vorgängen.

Gehen Sie eine echte Prüfung durch

Angenommen, die Benachrichtigungseinstellungen sind bereit zur Prüfung. Maya prüft die Kundenergebnisse, während Priya die vereinbarten Regressionstests ausführt. Leo klärt die verbleibenden Kommentare der Umsetzungsprüfung und verlinkt deren Nachweis.

Der erste Durchgang zeigt, dass die Einstellung korrekt gespeichert wird, der Tastaturfokus aber nach Auswahl von Save verschwindet. Das Team lässt die Barrierefreiheitsprüfung offen, dokumentiert das Problem im üblichen Jira-Austausch und behebt es, bevor die betreffende Prüfung wiederholt wird.

Auch die Support-Hinweise sind noch nicht fertig. Das bleibt sichtbar, obwohl die funktionsspezifischen Akzeptanzkriterien erfüllt sind. Die getrennten Listen erklären, warum noch Arbeit aussteht.

Wählen Sie nach einer tatsächlich bestandenen Prüfung deren Schaltfläche Done. Wählen Sie sie erneut, wenn neue Erkenntnisse den Eintrag wieder offen machen. Halten Sie Testergebnisse, Prüfverweise und wichtige Entscheidungen über Ihren normalen Jira- oder Dokumentationsprozess fest.

Ein erledigter Eintrag dokumentiert das Urteil des Teams. Er führt keine Prüfung aus, sammelt keine Belege und stellt nicht fest, wer geprüft hat. Sind Identität oder Zeitpunkt relevant, erfassen Sie diese Angaben ausdrücklich in Ihrem üblichen Prüfprozess.

Lesen Sie die Bereitschaftsanzeige sorgfältig

Das Werkzeug zeigt je Registerkarte die Zahl erledigter und aller Einträge. Die Bereitschaftsanzeige lautet nur dann Ready for Release, wenn beide Listen mindestens einen Eintrag enthalten und sämtliche Einträge erledigt sind. Andernfalls lautet sie In Verification.

Diese Regel hilft, offene Einträge zu erkennen. Sie erklärt auch, warum eine vollständig erledigte Definition-of-Done-Liste noch keinen vollständigen Abschluss anzeigt, solange Acceptance Criteria leer ist.

Verstehen Sie die Anzeige als Zusammenfassung des Checklistenstatus. Sie beweist weder ausreichende Prüfungen noch überzeugende Belege oder eine sichere Veröffentlichung. Ein schlecht formulierter Eintrag lässt sich genauso leicht als erledigt markieren wie ein hilfreicher.

Die Checkliste blockiert auch keinen Jira-Statuswechsel und keine Zusammenführung eines Pull Requests. Treffen Sie solche Entscheidungen weiterhin im normalen Auslieferungs- und Veröffentlichungsprozess Ihres Teams.

Halten Sie den Standard bei Veränderungen hilfreich

Prüfen Sie den Standard, wenn ein wiederholter Fehler eine fehlende Prüfung offenlegt, sich das Produkt wesentlich verändert oder eine bestehende Prüfung keine hilfreichen Informationen mehr liefert.

Das Portal-Team könnte beispielsweise feststellen, dass geänderte Einstellungen sofort funktionieren, aber nach verzögerter Synchronisierung fehlschlagen. Daraus könnte eine breitere Prüfregel für Funktionen mit zeitversetzter Verarbeitung entstehen. Zunächst sollte das Team klären, für welche Änderungen sie gilt und welche Belege den Erfolg zeigen.

Aktualisieren Sie den Referenzstandard und besprechen Sie die Anwendung auf laufende Arbeit. Bestehende Vorgangslisten übernehmen diese Änderung nicht automatisch. Prüfen Sie betroffene Vorgänge und ergänzen Sie die neu vereinbarten Prüfungen bei Bedarf manuell.

Erweitern Sie die Checkliste nicht nach jedem Einzelfehler. Manchmal ist ein bestimmtes Akzeptanzkriterium, eine klarere Umsetzungsaufgabe oder ein geänderter Prüfprozess die bessere Antwort. Der gemeinsame Standard sollte verständlich bleiben und tatsächlich angewendet werden können.

Probieren Sie es an einem aktuellen Vorgang aus

Wählen Sie einen Vorgang kurz vor der Prüfung. Vereinbaren Sie einen kurzen gemeinsamen Qualitätsstandard, tragen Sie ihn unter Definition of Done ein und ergänzen Sie die spezifischen Kundenergebnisse unter Acceptance Criteria.

Gehen Sie die Prüfungen gemeinsam durch und verlinken Sie die Belege am üblichen Ort Ihres Teams. Markieren Sie Einträge erst nach der Prüfung als erledigt und besprechen Sie die verbleibende Arbeit in Ihrem normalen Auslieferungsprozess.

Der Nutzen liegt in einem klareren Gespräch. Sagt jemand, die Änderung der Benachrichtigungseinstellungen sei fertig, kann das Team erklären, welche Ergebnisse funktionieren, welche Qualitätsprüfungen bestanden sind und worauf diese Einschätzung beruht.

• Der Scrum Guide — Definition of Done