In der Landschaft agiler Entwicklung ist Klarheit die Währung des Erfolgs. Wenn ein Team mit der Arbeit an einer neuen Funktion beginnt, liegt die Grundlage in der User Story. Eine User Story ist jedoch lediglich ein Platzhalter für ein Gespräch. Um dieses Gespräch in ein funktionierendes Produkt zu verwandeln, sind zwei entscheidende Artefakte erforderlich: Akzeptanzkriterien und Definition of Done. Diese Konzepte dienen als Leitplanken, die Qualität, Ausrichtung und Vorhersagbarkeit sicherstellen.
Viele Teams kämpfen mit der Unterscheidung zwischen diesen beiden Konzepten. Manchmal werden sie als dasselbe betrachtet, was zu Verwirrung während des Testens oder der Bereitstellung führt. In anderen Fällen werden sie gänzlich übersehen, was zu Scope Creep oder unvollständigen Funktionen führt, die in die Produktion gelangen. Dieser Leitfaden untersucht die Mechanik, den Zweck und die Umsetzung von Akzeptanzkriterien und Definition of Done, um Ihrem Team zu helfen, kontinuierlich Wert zu liefern.
Was ist eine User Story? 📝
Bevor man die Bestandteile einer Geschichte analysiert, ist es unerlässlich, sich daran zu erinnern, was eine User Story eigentlich ist. In agilen Frameworks ist eine User Story eine kurze, einfache Beschreibung einer Funktion, erzählt aus der Perspektive der Person, die die neue Fähigkeit wünscht. Sie folgt typischerweise dem Format:
- Als ein [Art des Benutzers],
- möchte ich [einige Ziel],
- damit [einige Vorteil].
Dieses Format konzentriert sich auf die Wertdem Nutzer bereitgestellte Wert, anstatt auf die technische Umsetzung. Allerdings reicht dieses Format allein nicht aus, um die Entwicklung zu leiten. Es legt weder die Grenzen der Arbeit noch die Standards für die Fertigstellung fest. Hier setzen Akzeptanzkriterien und Definition of Done ein.
Akzeptanzkriterien (AC): Die Bedingungen für die Fertigstellung ✅
Akzeptanzkriterien sind eine Reihe von Bedingungen, die eine User Story erfüllen muss, um aus Sicht des Product Owners als abgeschlossen betrachtet zu werden. Sie definieren die Grenzen der Geschichte und vermitteln ein klares Verständnis dafür, wie das Endprodukt aussehen soll.
Der Zweck der Akzeptanzkriterien
Akzeptanzkriterien erfüllen mehrere Funktionen im Entwicklungszyklus:
- Klärung: Sie beseitigen Mehrdeutigkeit. Wenn ein Entwickler fragt: „Soll der Button bei Hover grün oder blau werden?“, sollten die AC diese Frage beantworten.
- Testen: Sie fungieren als Testfälle. QA-Engineer verwenden diese Bedingungen, um die Funktion zu validieren.
- Einvernehmen: Sie stellen sicher, dass Product Owner und Entwicklungsteam sich darauf einigen, was für diese spezifische Geschichte als „abgeschlossen“ gilt.
Eigenschaften guter Akzeptanzkriterien
Effektive Akzeptanzkriterien sind spezifisch, messbar und eindeutig. Vermeiden Sie vage Begriffe wie „benutzerfreundlich“ oder „schnell“, ohne Metriken zu definieren. Geben Sie stattdessen genaue Verhaltensweisen an.
- Atomar: Jedes Kriterium sollte sich auf eine einzelne Anforderung beziehen.
- Prüfbar: Es muss möglich sein, das Kriterium mit einem Erfolg oder Misserfolg zu überprüfen.
- Unabhängig:Die Kriterien sollten sich nicht auf externe Geschichten stützen, um validiert zu werden.
- Relevant:Konzentriere dich auf den Nutzen für den Nutzer, nicht auf die interne Codestruktur.
Beispiele für Akzeptanzkriterien
Stelle dir eine Geschichte vor, bei der eine Funktion „Passwort vergessen“ hinzugefügt wird. So könnte ein Akzeptanzkriterium aussehen:
- Gegeben, dass der Benutzer auf der Anmeloseite ist,
Wenn sie auf den Link „Passwort vergessen“ klicken,
Dann werden sie auf die Seite zur Passwortwiederherstellung weitergeleitet. - Gegeben, dass der Benutzer eine gültige E-Mail-Adresse eingibt,
Wenn sie das Formular absenden,
Dann wird eine Bestätigungs-Nachricht angezeigt. - Gegeben, dass der Benutzer eine ungültige E-Mail-Adresse eingibt,
Wenn sie das Formular absenden,
Dann wird eine Fehlermeldung anzeigen, dass das E-Mail-Format falsch ist.
Diese Beispiele folgen der Gegeben/Wenn/DannStruktur (oft mit der Gherkin-Syntax verbunden), die Klarheit fördert und mit automatisierten Testframeworks übereinstimmt.
Definition des Fertigstellens (DoD): Die Qualitätskontrolle 🚧
Während Akzeptanzkriterien spezifisch für eine einzelne Nutzergeschichte sind, ist die Definition des Fertigstellens ein globales Standardverfahren, das auf alleArbeit innerhalb eines Sprints oder Releases angewendet wird. Sie stellt die Prüfliste der Anforderungen dar, die erfüllt sein müssen, damit jeder Arbeitsschritt als potenziell lieferbar betrachtet werden kann.
Der Zweck der Definition des Fertigstellens
Die DoD wirkt als Qualitätskontrolle. Sie stellt sicher, dass technische Schulden sich nicht ansammeln und dass das Produkt jederzeit in einem lieferbaren Zustand bleibt. Wenn eine Geschichte ihre Akzeptanzkriterien erfüllt, aber die Definition des Fertigstellens nicht erfüllt, kann sie nicht als abgeschlossen markiert werden.
Häufige Elemente in einer Definition des Fertigstellens sind:
- Code-Review:Der gesamte Code muss von mindestens einem Kollegen überprüft werden.
- Einheitstests:Automatisierte Tests müssen mit 100 % Abdeckung für die neue Logik bestehen.
- Dokumentation: Die API-Dokumentation oder Benutzerhandbücher werden aktualisiert.
- Leistung: Die Funktion erfüllt die Mindestanforderungen an die Ladezeit.
- Barrierefreiheit: Die Funktion entspricht den WCAG-Richtlinien.
- Sicherheit: Es werden keine bekannten Sicherheitslücken eingeführt.
Warum der Definition des Fertigstellungsstatus (DoD) wichtig ist
Ohne eine Definition des Fertigstellungsstatus geraten Teams oft in die Falle von „technisch abgeschlossen, aber tatsächlich nicht bereit“. Eine Funktion könnte gemäß den Akzeptanzkriterien wie vorgesehen funktionieren, aber einen anderen Teil des Systems beschädigt haben, fehlende Dokumentation aufweisen oder Sicherheitsrisiken beinhalten. Der DoD verhindert dies, indem er eine Mindestqualität über die gesamte Backlog hinweg durchsetzt.
Akzeptanzkriterien im Vergleich zur Definition des Fertigstellungsstatus: Die wesentlichen Unterschiede 🆚
Verwirrung entsteht oft, weil beide Konzepte mit der „Vollständigkeit“ zu tun haben. Ihre Reichweite und Verantwortung unterscheiden sich jedoch erheblich. Das Verständnis des Unterschieds verhindert Missverständnisse zwischen Entwicklern, Testern und Product Owners.
| Funktion | Akzeptanzkriterien | Definition des Fertigstellungsstatus |
|---|---|---|
| Umfang | Spezifisch für eine einzelne User Story | Global für das gesamte Team oder Projekt |
| Verantwortung | Product Owner und Entwicklungsteam | Gesamtes Entwicklungsteam |
| Flexibilität | Änderungen pro Story basierend auf Anforderungen | Stabil, kann jedoch im Laufe der Zeit aktualisiert werden |
| Zweck | Definiert funktionale Anforderungen | Definiert Qualitäts- und nicht-funktionale Standards |
| Verifikation | Funktionstests anhand der Nutzerbedürfnisse | Technische und prozessuale Überprüfung |
Stellen Sie sich die Akzeptanzkriterien als Ziel einer bestimmten Reise vor, während die Definition des Fertigstellungsstatus die Sicherheitsprüfliste für jedes Fahrzeug auf der Straße ist.
Wie man wirksame Akzeptanzkriterien schreibt 📝
Die Erstellung von Akzeptanzkriterien ist eine gemeinsame Aufgabe. Sie sollte nicht isoliert durch den Product Owner erfolgen. Die beste Praxis beinhaltet das Konzept der „Drei Freunde“, bei dem der Product Owner, ein Entwickler und ein Tester bereits früh im Refinement-Prozess zusammenarbeiten.
Schritt 1: Identifizieren des Nutzerziels
Beginnen Sie damit, das Wertversprechen neu zu formulieren. Welches Problem löst der Nutzer? Dadurch bleibt sichergestellt, dass die Kriterien auf die Nutzererfahrung statt auf technische Details fokussiert sind.
Schritt 2: Definieren positiver und negativer Szenarien
Schreiben Sie nicht nur den glücklichen Pfad. Berücksichtigen Sie, was passiert, wenn Dinge schief laufen.
- Glücklicher Pfad: Der Nutzer führt die Aktion genau so aus, wie erwartet.
- Randfälle: Was passiert bei Sonderzeichen, fehlenden Daten oder langsamen Verbindungen?
- Negativer Pfad: Wie behandelt das System ungültige Eingaben reibungslos?
Schritt 3: Klare Sprache verwenden
Vermeiden Sie Fachjargon, wenn möglich. Falls technische Begriffe notwendig sind, stellen Sie sicher, dass sie definiert sind. Verwenden Sie die aktive Stimme. Zum Beispiel ist „Das System muss validieren…“ weniger klar als „Der Nutzer erhält eine Fehlermeldung…“.
Schritt 4: Priorisieren
Wenn eine Geschichte groß ist, zerlegen Sie sie. Die Akzeptanzkriterien sollten innerhalb des Sprints erreichbar sein. Wenn die Kriterien Arbeit voraussetzen, die nicht innerhalb des Sprints abgeschlossen werden kann, muss die Geschichte aufgeteilt werden.
Wie man eine robuste Definition des Fertigstellungsstatus etabliert 🛠️
Die Definition des Fertigstellungsstatus ist kein statisches Dokument. Sie entwickelt sich weiter, je weiter das Team reift und je sich die Technologie verändert. Sie sollte für alle sichtbar sein, oft an einer physischen oder digitalen Tafel angebracht.
Schritt 1: Mit dem Team abstimmen
Die Definition des Fertigstellungsstatus gehört dem Team, das die Arbeit erledigt. Entwickler, Tester und Designer sollten zur Liste beitragen. Wenn ein Entwickler eine Anforderung hinzufügt, ist er eher dazu bereit, sie einzuhalten.
Schritt 2: Anforderungen kategorisieren
Ordnen Sie die DoD-Elemente in logische Kategorien, um die Prüfliste übersichtlich zu halten.
- Codequalität: Linting erfolgreich, keine Warnungen, Peer-Review abgeschlossen.
- Testen: Einheitstests geschrieben, Integrations-Tests bestanden, manuelle Tests bestätigt.
- Bereitstellung: Bereitgestellt im Staging-System, Smoke-Tests bestanden.
- Dokumentation: Readme aktualisiert, API-Dokumentation synchronisiert.
Schritt 3: Mach es zu einem harten Stop
Wenn eine Geschichte die Definition des Fertigstellens (DoD) nicht erfüllt, kann sie nicht geschlossen werden. Dafür ist Disziplin erforderlich. Es ist verlockend zu sagen: „Wir werden die Dokumentation später verbessern“, aber das schafft technische Schulden. Die Geschichte bleibt in „In Bearbeitung“, bis die DoD erfüllt ist.
Schritt 4: Überprüfen und Verfeinern
Stellen Sie während der Retrospektiven die Frage an das Team: „Hat unsere DoD irgendwelche Probleme aufgedeckt?“ oder „Gibt es eine Anforderung, die wir stets übersehen?“ Aktualisieren Sie die DoD basierend auf diesen Erkenntnissen.
Häufige Fehler, die Sie vermeiden sollten ⚠️
Sogar erfahrene Teams stolpern bei der Umsetzung dieser Praktiken. Die Kenntnis häufiger Fallstricke kann erhebliche Zeit und Frustration sparen.
1. Vage Akzeptanzkriterien
Kriterien wie „Das System sollte sicher sein“ zu formulieren, ist nutzlos. Sie sind nicht testbar. Geben Sie stattdessen an: „Das System muss für Admin-Konten eine mehrstufige Authentifizierung erfordern.“
2. DoD als einfache Kästchenabnahme
Wenn das Team die DoD-Kontrollkästchen abhakt, ohne die Arbeit tatsächlich zu erledigen (z. B. den Code-Review überspringt), verliert die DoD ihre Bedeutung. Die DoD muss respektiert werden, nicht nur gelesen.
3. Die DoD zu kompliziert gestalten
Eine DoD mit 50 Punkten wird überwältigend. Konzentrieren Sie sich auf die wesentlichen Qualitätsprüfungen. Wenn eine Anforderung selten verletzt wird, könnte sie eher ein Leitfaden als ein festes DoD-Kriterium sein.
4. Nicht-funktionale Anforderungen ignorieren
Teams konzentrieren sich oft stark auf AC (funktionale Anforderungen) und ignorieren die DoD (nicht-funktionale Anforderungen). Leistungsfähigkeit, Sicherheit und Barrierefreiheit sind Teil der DoD, nicht der AC. Ihre Vernachlässigung führt zu Funktionen, die funktionieren, aber langsam oder unsicher sind.
5. DoD ohne Team-Unterstützung erstellen
Wenn der Product Owner die DoD ohne Einbindung der Entwickler festlegt, könnte das Team dagegen ankämpfen. Die DoD muss eine gemeinsame Vereinbarung sein.
Integration in den Arbeitsablauf 🔄
Akzeptanzkriterien und die Definition des Fertigstellens sollten in jedes Stadium des Entwicklungslebenszyklus integriert werden, nicht nur am Ende.
Refinement-Phase
Während der Backlog-Refinement erstellt der Product Owner die Akzeptanzkriterien. Das Team prüft sie daraufhin, ob sie testbar und realisierbar sind. Fragen werden hier gestellt und beantwortet, nicht während des Sprints.
Sprint-Planung
Beim Verpflichten zu Geschichten überprüft das Team, ob die Akzeptanzkriterien klar sind. Wenn nicht, ist die Geschichte nicht für den Sprint bereit.
Entwicklungsphase
Entwickler schreiben Code, um die AC zu erfüllen. Gleichzeitig stellen sie sicher, dass sie die DoD einhalten (z. B. Tests schreiben, Reviews anfordern).
Testphase
QA-Engineer überprüfen die AC anhand des entwickelten Features. Sie überprüfen auch die DoD (z. B. Code-Coverage-Reports, Barrierefreiheitsprüfungen).
Überprüfung und Abschluss
Bevor eine Geschichte in „Erledigt“ verschoben wird, bestätigt das Team, dass sowohl die AC als auch die DoD erfüllt sind. Falls nicht, kehrt sie in die Warteschlange zurück.
Erfolg messen 📊
Wie erkennen Sie, ob Ihre Akzeptanzkriterien und die Definition des Fertigstellens funktionieren? Verfolgen Sie Metriken über die Zeit.
- Fehlerquote: Werden Fehler in der Produktion weniger? Ein starkes DoD sollte Probleme vor der Freigabe erkennen.
- Ablehnungsrate: Werden Geschichten häufig vom Product Owner abgelehnt? Das deutet auf eine schlechte Definition der Akzeptanzkriterien hin.
- Stabilität der Geschwindigkeit: Bleibt die Geschwindigkeit des Teams stabil? Wenn Geschichten häufig aufgrund fehlender DoD-Angaben zurückgegeben werden, wird die Geschwindigkeit schwanken.
- Häufigkeit der Bereitstellung: Erlaubt ein klares DoD eine reibungslosere und häufigere Bereitstellung?
Häufig gestellte Fragen ❓
Hier sind häufig gestellte Fragen, die Teams stellen, wenn sie diese Standards umsetzen.
F: Können Akzeptanzkriterien während eines Sprints geändert werden?
A: Idealerweise nein. Wenn sich die Akzeptanzkriterien erheblich ändern, könnte das darauf hindeuten, dass die Geschichte während der Vorbereitung nicht gut verstanden wurde. Kleine Klärungen sind akzeptabel, aber umfangreiche Änderungen des Umfangs sollten zu einer neuen Geschichte oder einer Anpassung des Sprint-Umfangs führen.
F: Braucht jede Geschichte eine eindeutige Definition des Fertigstellungsstatus?
A: Nein. Die DoD ist global gültig. Allerdings können bestimmte technische Geschichten zusätzliche Anforderungen auf der Checkliste für diese spezifische Aufgabe enthalten, aber die Grund-DoD gilt für alle.
F: Was passiert, wenn die Teammitglieder sich nicht einig über die DoD sind?
A: Führen Sie eine Diskussion durch. Ziel ist Konsens. Wenn ein Entwickler eine Anforderung durchsetzen möchte, die der Tester ablehnt, besprechen Sie das Risiko. Wenn das Risiko gering ist, lassen Sie es weg. Wenn es hoch ist, behalten Sie es.
F: Wie detailliert sollten die Akzeptanzkriterien sein?
A: So detailliert, dass sie getestet werden können. Wenn ein QA-Engineer direkt aus den Akzeptanzkriterien einen Testfall schreiben kann, sind sie ausreichend detailliert. Wenn sie Fragen stellen müssen, braucht es mehr Detail.
F: Kann automatisiertes Testen manuelles Testen in der DoD ersetzen?
A: Es hängt ab. Für kritische Logik ja. Für Benutzererfahrung oder visuelle Elemente könnte manuelles Validieren immer noch erforderlich sein. Die DoD sollte die beste Praxis für Qualitätssicherung widerspiegeln.
Abschließende Gedanken zur Qualität und Ausrichtung 🌟
Die Umsetzung von Akzeptanzkriterien und Definition des Fertigstellungsstatus geht nicht um Bürokratie; es geht um Respekt. Respekt gegenüber dem Nutzer, der eine funktionierende Funktion erwartet, Respekt gegenüber dem Entwickler, der klare Anforderungen möchte, und Respekt gegenüber dem Product Owner, der Vertrauen in die Lieferung braucht.
Wenn diese beiden Konzepte richtig eingesetzt werden, schaffen sie eine gemeinsame Sprache für das Team. Sie reduzieren die Notwendigkeit ständiger Klärungsgespräche. Sie verhindern die Ansammlung technischer Schulden. Und vor allem stellen sie sicher, dass jede abgeschlossene Geschichte echten Wert für das Produkt bringt.
Fangen Sie klein an. Definieren Sie eine grundlegende DoD. Schreiben Sie klare Akzeptanzkriterien für Ihre nächste Geschichte. Prüfen Sie sie in Ihrem nächsten Retrospektiv. Im Laufe der Zeit werden diese Praktiken zur zweiten Natur, fest verankert in der Kultur Ihres Teams. Das Ergebnis ist ein stetiger Fluss hochwertiger Software, die die Bedürfnisse der Menschen erfüllt, die sie nutzen.