Agile-Leitfaden: Definieren von „Done“ – Erstellen klarer Akzeptanzkriterien für Stories

In der schnellen Umgebung agiler Entwicklung ist Unklarheit der Feind des Fortschritts. Wenn ein Team eine Benutzerstory ohne klare Grenzen erhält, divergieren die Erwartungen, was zu Nacharbeit, verzögerten Releases und Frustration führt.Akzeptanzkriterien und die Definition von „Done“sind nicht nur administrative Aufgaben; sie sind die grundlegenden Verträge zwischen Stakeholdern und dem Entwicklerteam. Sie definieren, wie Erfolg aussehen soll, noch bevor ein einziger Codezeile geschrieben wurde.

Dieser Leitfaden untersucht die Mechanismen zur Erstellung präziser Akzeptanzkriterien und zur Festlegung einer robusten Definition von „Done“. Wir werden untersuchen, wie diese Elemente die Qualität fördern, Verschwendung reduzieren und sicherstellen, dass jeder Sprint greifbaren Wert liefert. Am Ende dieses Dokuments werden Sie verstehen, wie Sie Ihren Backlog strukturieren, um Unklarheiten zu minimieren und die Lieferzuversicht zu maximieren.

🧩 Verständnis von Akzeptanzkriterien im Vergleich zur Definition von „Done“

Obwohl sie von Anfängern in der Methodik oft synonym verwendet werden, Akzeptanzkriterien (AK) und Definition von „Done“ (DoD)erfüllen unterschiedliche Zwecke. Die Verwechslung beider kann dazu führen, dass Stories technisch abgeschlossen sind, aber die geschäftlichen Anforderungen nicht erfüllen, oder dass Stories geschäftlich bereit sind, aber die technischen Standards nicht erfüllen.

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind eine spezifische Reihe von Bedingungen, die eine Benutzerstory erfüllen muss, um aus geschäftlicher Sicht als abgeschlossen angesehen zu werden. Sie sind für jede Story einzigartig. Wenn eine Story über „Anmelden“ geht, definieren die AKs, was einen erfolgreichen Anmeldevorgang ausmacht. Wenn eine Story über „Anzeigen eines Dashboards“ geht, definieren die AKs, welche Daten angezeigt werden und wie sie aktualisiert werden.

• Umfang:Spezifisch für die einzelne Benutzerstory.

• Zweck:Die Überprüfung funktionalen Verhaltens und geschäftlichen Nutzens.

• Verantwortung:Typischerweise definiert vom Product Owner in Zusammenarbeit mit dem Team.

• Beispiel: „Das System soll Benutzern erlauben, ihr Passwort per E-Mail innerhalb von 5 Minuten zurückzusetzen.“

Was ist die Definition von „Done“?

Die Definition von „Done“ ist ein gemeinsames Verständnis dafür, was es bedeutet, dass Arbeit im gesamten Projekt abgeschlossen ist. Es ist eine Checkliste, die auf jedeStory anwendbar ist, unabhängig vom Inhalt. Sie stellt die Qualitätsgrundlage des Produkts dar.

• Umfang:Gilt für alle Arbeitselemente im Backlog.

• Zweck: Um eine einheitliche Qualität und technische Integrität sicherzustellen.

• Eigentum: Gemeinsam von dem Entwicklungsteam gehalten.

• Beispiel: „Der Code wurde geprüft, Einheitstests bestanden und die Dokumentation aktualisiert.“

Funktion	Akzeptanzkriterien	Definition des Fertiggestelltseins
Feinheit	Spezifisch für eine Geschichte	Universell für alle Geschichten
Fokus	Geschäftsfunktion	Technische Qualität & Standards
Entwicklung	Änderungen pro Geschichte	Statisch oder entwickelt sich langsam
Beispiel	„Die Schaltfläche wird bei Klick grün“	„Keine Konsolenfehler vorhanden“

📝 Die Anatomie eines hochwertigen Akzeptanzkriteriums

Die Erstellung wirksamer Akzeptanzkriterien erfordert eine Verschiebung von vagen Wünschen hin zu messbaren Bedingungen. Ein Kriterium ist keine Aufgabe; es ist eine überprüfbare Bedingung. Wenn die Kriterien schwach sind, wird die Testphase zu einem Ratespiel. Wenn sie stark sind, wird die Testphase zu einem Überprüfungsprozess.

Eigenschaften wirksamer Kriterien

Um Klarheit zu gewährleisten, sollten Akzeptanzkriterien bestimmten Prinzipien folgen. Diese Prinzipien helfen dem Team, Missverständnisse zu vermeiden und sicherzustellen, dass alle dasselbe mentale Modell der Funktion teilen.

• Zweideutig: Verwenden Sie Wörter wie „schnell“, „einfach“ oder „benutzerfreundlich“ nicht. Verwenden Sie stattdessen konkrete Metriken, wie beispielsweise „lädt in weniger als 2 Sekunden“ oder „erfordert 3 Klicks, um abgeschlossen zu werden.“

• Prüfbar: Wenn Sie keinen Testfall dafür schreiben können, ist es kein gültiges Kriterium. Jedes Kriterium muss ein Ergebnis von Bestanden oder Nicht-bestanden liefern.

• Vollständig: Decken Sie glückliche Pfade, Randfälle und negative Szenarien ab. Was passiert, wenn die Eingabe leer ist? Was passiert, wenn das Netzwerk ausfällt?

• Unabhängig: Während Geschichten von anderen Geschichten abhängen können, sollten die Kriterien einer Geschichte nicht von den Kriterien einer anderen abhängen, um gültig zu sein.

• Wertvoll: Konzentriere dich auf das, was der Nutzer erlebt. Technische Implementierungsdetails sind meist besser für die Definition des Fertigstellungsstatus oder technische Anmerkungen geeignet.

Schreibtechniken

Es gibt strukturierte Ansätze zum Schreiben von Kriterien, die die Konsistenz innerhalb des Teams verbessern. Die Verwendung dieser Formate verringert die kognitive Belastung beim Überprüfen von Backlog-Elementen.

1. Das Gegeben-Wenn-Dann-Format

Auch bekannt als Gherkin-Syntax, strukturiert dieses Format Kriterien in eine Szene. Es trennt den Kontext, die Aktion und das erwartete Ergebnis.

• Gegeben: Der ursprüngliche Zustand oder Kontext.

• Wenn: Das Ereignis oder die Aktion, die der Nutzer unternimmt.

• Dann: Das beobachtbare Ergebnis, das bestätigt, dass die Funktion funktioniert.

Beispiel:

• Gegeben der Nutzer ist mit einem aktiven Abonnement angemeldet

• Wenn sie zur Abrechnungsseite navigieren

• Dann werden das aktuelle Abonnement und das nächste Verlängerungsdatum angezeigt

2. Das Prüfzett-Format

Für einfachere Geschichten reicht oft eine direkte Liste von Bedingungen aus. Dieses Format eignet sich am besten für UI-Änderungen oder einfache Datenaktualisierungen.

• Stelle sicher, dass die Schaltfläche „Absenden“ deaktiviert ist, wenn das Formular leer ist.

• Stelle sicher, dass die Fehlermeldung in roter Schrift unter dem Eingabefeld angezeigt wird.

• Bestätige, dass die API-Antwort einen Statuscode 200 zurückgibt.

3. Das regelbasierte Format

Einige Funktionen hängen stark von Geschäftslogik ab. Die explizite Aufzählung dieser Regeln verhindert Logikfehler während der Entwicklung.

• Rabatte gelten nur für Artikel mit einem Preis von mehr als 10 US-Dollar.

• Benutzer unter 18 Jahren können auf die Premium-Ebene nicht zugreifen.

• Die maximale Dateigröße für Uploads beträgt 10 MB.

🤝 Zusammenarbeit bei der Verbesserung

Akzeptanzkriterien werden nicht isoliert verfasst. Sie entstehen durch Zusammenarbeit. Der Product Owner bringt den geschäftlichen Kontext ein, während das Entwicklungsteam die technische Umsetzbarkeit einbringt. Diese Zusammenarbeit findet während derBacklog-Optimierung Sitzungen.

Wer sollte beteiligt sein?

Während der Product Owner der Hauptverfasser der Kriterien ist, steigt ihr Wert erheblich, wenn andere beitragen.

• Product Owner: Definiert das „Was“ und das „Warum“. Stellt sicher, dass die Kriterien die Nutzerbedürfnisse widerspiegeln.

• Entwickler: Identifizieren technische Beschränkungen. Sie klären, was innerhalb der aktuellen Architektur möglich ist.

• QA / Tester: Fokussieren sich auf Randfälle. Sie fragen: „Was bringt dies zum Absturz?“ und „Wie messen wir Erfolg?“

• Designer: Stellen sicher, dass visuelle und interaktive Kriterien den Designvorgaben entsprechen.

Wann sollte man optimieren?

Die Optimierung ist eine kontinuierliche Tätigkeit, kein einmaliger Vorgang. Ziel ist es sicherzustellen, dass die Geschichten für die nächste Sprint-Planung bereit sind. Eine gängige Faustregel besagt, dass 50 % bis 75 % des Backlogs des nächsten Sprints optimiert und bereit zur Umsetzung sein sollten.

• Frühphase: Grobe Skizzen. Fokus auf den Hauptnutzen und die groben Abläufe.

• Mittlere Phase:Detaillierung von Randfällen und spezifischen Datenanforderungen.

• Vor dem Sprint:Endgültige Überprüfung. Sicherstellen, dass keine Unklarheiten mehr bestehen, bevor eine Verpflichtung eingegangen wird.

⚠️ Häufige Fehler und wie man sie vermeidet

Sogar erfahrene Teams haben Schwierigkeiten mit Akzeptanzkriterien. Die Erkennung häufiger Fehler ermöglicht es Ihnen, rechtzeitig Korrekturen vorzunehmen, bevor sie die Lieferung beeinträchtigen.

1. Schreiben von Aufgaben statt Kriterien

Ein häufiger Fehler ist das Auflisten von Implementierungsschritten. „Eine Datenbanktabelle erstellen“ ist eine Aufgabe. „Daten bleiben über Sitzungen hinweg erhalten“ ist ein Kriterium. Aufgaben gehören in den Entwicklungsplan, nicht in die Akzeptanzkriterien.

2. Übermäßige Spezifizierung

Zu viele Details können die Innovation hemmen. Wenn Sie den Entwicklern genau sagen, wie ein Problem gelöst werden soll, beschränken Sie ihre Fähigkeit, bessere Lösungen zu finden. Konzentrieren Sie sich auf das Verhalten, nicht auf die Mechanismen.

3. Vernachlässigung von Nicht-Funktionalen Anforderungen

Leistungsfähigkeit, Sicherheit und Barrierefreiheit werden oft übersehen. Eine Funktion, die funktioniert, aber unsicher oder nicht barrierefrei ist, ist nicht abgeschlossen. Fügen Sie Kriterien für folgendes hinzu:

• Leistungsfähigkeit: „Die Seite lädt in weniger als 2 Sekunden.“

• Barrierefreiheit: „Bildschirmleser können das Formular navigieren.“

• Sicherheit: „Passwörter werden vor der Speicherung gehasht.“

4. Mehrdeutige Sprache

Wörter wie „optimiert“, „robust“ oder „modern“ sind subjektiv. Ersetzen Sie sie durch messbare Standards. „Optimiert“ wird zu „Reduziert API-Aufrufe um 20 %“. „Robust“ wird zu „Verarbeitet 1.000 gleichzeitige Benutzer ohne Fehler.“

🔄 Die Definition des Fertigstellens: Sicherstellung der Konsistenz

Während die Akzeptanzkriterien sicherstellen, dass die Funktion für den Benutzer funktioniert, stellt die Definition des Fertigstellens sicher, dass der Code sicher freigegeben werden kann. Eine DoD wirkt als Schleuse. Wenn eine Geschichte die DoD nicht erfüllt, kann sie nicht in den Status „Erledigt“ überführt werden, unabhängig davon, ob die Akzeptanzkriterien erfüllt sind.

Bestandteile einer starken Definition des Fertigstellens

Eine umfassende DoD deckt den gesamten Lebenszyklus einer Codeänderung ab. Sie sollte für alle sichtbar sein, oft auf einer physischen Tafel oder einer digitalen Dashboard angezeigt.

• Codequalität: Keine Code-Schimmel, Linting-Prüfungen bestanden, Komplexitätsschwellen erreicht.

• Testen: Einheitstests geschrieben und bestanden, Integrations-Tests bestanden, manuelles Testen bestätigt.

• Dokumentation: Benutzerdokumentation aktualisiert, API-Dokumentation aktualisiert, interne Wissensdatenbank verknüpft.

• Sicherheit: Abhängigkeitsprüfung bestanden, keine verschlüsselten Geheimnisse im Code, Schwachstellenprüfung bestanden.

• Bereitstellung: Code in den Hauptzweig integriert, in Staging bereitgestellt, in der Produktionsumgebung verifiziert.

Verfeinerung der Definition des Fertigstellens

Die DoD ist nicht statisch. Je weiter sich das Team entwickelt und je mehr sich die Technologie ändert, desto mehr sollte die DoD sich weiterentwickeln. Wenn ein neues Testwerkzeug eingeführt wird, sollte die DoD die Verpflichtung zur Nutzung dieses Werkzeugs widerspiegeln. Wenn ein Sicherheitsstandard aktualisiert wird, muss die DoD sich anpassen.

• Regelmäßige Überprüfung: Besprechen Sie die DoD während der Retrospektiven. Ist sie zu schwer? Ist sie zu leicht?

• Schrittweise Erweiterung: Fügen Sie Schritt für Schritt neue Elemente hinzu. Verdoppeln Sie die DoD nicht über Nacht. Dadurch werden Engpässe vermieden.

• Team-Konsens: Das Team muss sich auf die Definition des Fertigstellens einigen. Wenn Entwickler meinen, es sei unmöglich, werden sie sie umgehen, was ihren Zweck zunichtemacht.

📈 Messung von Einfluss und Qualität

Die Investition von Zeit in die Definition von „Fertiggestellt“ und Akzeptanzkriterien bringt messbare Ergebnisse. Teams, die Klarheit priorisieren, sehen Verbesserungen in Geschwindigkeit, Vorhersagbarkeit und Qualität.

Wichtige Metriken zur Verfolgung

• Fehler-Entweichungsrate: Die Anzahl der Fehler, die in der Produktion gefunden werden. Klare Kriterien verringern die Wahrscheinlichkeit, dass Logikfehler an die Benutzer gelangen.

• Anteil der Nacharbeit: Wie viel Arbeit wird nach der ersten Fertigstellung rückgängig gemacht oder geändert. Mehrdeutige Kriterien führen oft zu Nacharbeit.

• Einhaltung der Definition des Fertigstellens: Wie viele Stories sind als „Fertiggestellt“ markiert, die tatsächlich die vollständige DoD-Checkliste erfüllt haben.

• Zeit für die Nacharbeit: Zeit, die für die Diskussion der Kriterien aufgewendet wird. Obwohl dies zu Beginn Zeit kostet, reduziert es die Zeit, die während der Entwicklung für Klärungen benötigt wird.

Feedback-Schleifen

Die Qualität Ihrer Kriterien kann durch Feedback-Schleifen bewertet werden. Wenn ein QA-Engineer häufig Probleme findet, die durch die Kriterien abgedeckt sein sollten, müssen die Kriterien überarbeitet werden. Wenn Entwickler während der Entwicklung häufig klärende Fragen stellen, benötigen die Kriterien mehr Detail.

Nutzen Sie das Retrospektiv, um diese Themen zu besprechen. Fragen Sie die Mannschaft:

• Haben wir irgendeine Geschichte missverstanden?

• Gibt es Randfälle, die wir übersehen haben?

• War die Definition des Fertigstellens innerhalb des Sprint-Zeitrahmens erreichbar?

🛠️ Praktische Umsetzungsschritte

Die Implementierung eines robusten Systems für Akzeptanzkriterien und die Definition des Fertigstellens erfordert einen strukturierten Ansatz. Folgen Sie diesen Schritten, um diese Praktiken in Ihren Arbeitsablauf zu integrieren.

Schritt 1: Festlegung der Grundlage

Beginnen Sie damit, die minimale Definition des Fertigstellens zu definieren. Was ist das absolute Minimum, das erforderlich ist, um Code als sicher zu betrachten? Dazu könnten „Kompiliert“, „Läuft lokal“ und „Grundlegende Tests“ gehören. Bringen Sie die Mannschaft sofort dazu, sich auf diese Grundlage zu einigen.

Schritt 2: Schulung zum Schreiben von Kriterien

Führen Sie Workshops durch, um die Mannschaft zu lehren, Given-When-Then-Szenarien zu schreiben. Verwenden Sie echte Stories aus dem Backlog als Übungsbeispiele. Dadurch stellen Sie sicher, dass alle das erwartete Format und die Tiefe verstehen.

Schritt 3: Integration in den Arbeitsablauf

Machen Sie die Kriterien zu einem Pflichtfeld in Ihrem Verfolgungssystem. Stories ohne Kriterien können nicht in den Status „Bereit für Sprint-Planung“ verschoben werden. Dies fördert die Disziplin, ohne eine Mikroverwaltung zu erfordern.

Schritt 4: Überprüfung während der Planung

Weisen Sie Zeit im Sprint-Planungsmeeting zur Überprüfung der Kriterien ausgewählter Stories an. Wenn eine Story unklar ist, verpflichten Sie sich nicht dazu. Schieben Sie sie zurück zur Nacharbeit. Dies schützt die Mannschaft vor der Übernahme mehrdeutiger Arbeit.

Schritt 5: Kontinuierliche Verbesserung

Überprüfen Sie die Kriterien nach dem Sprint. Hielten sie stand? Haben sie die Probleme erfasst, die sie erfassen sollten? Aktualisieren Sie die Vorlagen und Standards basierend auf diesen Erkenntnissen.

🌟 Vorwärtsbewegung

Klare Akzeptanzkriterien und eine solide Definition des Fertigstellungsstatus sind keine Abkürzungen; sie sind die Grundlage für zuverlässige Agile-Lieferung. Sie verwandeln die Entwicklung von einem Ratespiel in einen vorhersehbaren Prozess. Indem Teams Zeit investieren, um im Vorfeld festzulegen, wie Erfolg aussehen soll, reduzieren sie Verschwendung, steigern die Motivation und liefern qualitativ hochwertigere Software.

Die Reise zur Klarheit ist kontinuierlich. Sie erfordert Disziplin, um an den Standards festzuhalten, und Mut, um vage Anforderungen zurückzuweisen. Wenn Sie Ihre Prozesse verfeinern, werden Sie feststellen, dass die Zeit, die Sie für die Definition von Fertig gestellt aufwenden, Zeit spart bei Debugging, Nacharbeit und Stakeholder-Management. Konzentrieren Sie sich auf Präzision, fördern Sie die Zusammenarbeit und lassen Sie die Qualität Ihrer Kriterien die Qualität Ihres Produkts bestimmen.