Acceptance Criteria vs. Definition of Done vs. Ready
Definition of Done ist auf jeder Story gleich: Tests, Review, Docs. Acceptance Criteria ändern sich mit der Arbeit — „Account Owner kann CSV in unter fünf Sekunden exportieren.“ Definition of Ready fragt, ob diese Beispiele existieren, bevor Sie starten. Die QA-Testcheckliste ist, wie Sie sie beweisen. Alle drei als Checklisten auf dem Arbeitselement verbessern Klarheit und reduzieren Mehrdeutigkeit — Status und nächste Schritte sind sichtbar, ohne Schnitzeljagd.
Ein Beispiel: eine API, die Jira-Vorgänge listet
Acceptance Criteria unterscheiden sich in der Regel von Story zu Story — jede Liste beschreibt, was dieses Arbeitselement liefern soll. Stellen Sie sich ein Backlog-Item vor, das Ihr Team wirklich aufnehmen könnte: einen GET-Endpunkt bauen, der eine paginierte Liste von Jira-Vorgängen für ein Projekt zurückgibt. Produkt will Felder und Berechtigungen klar. Engineering will Pagination und Fehlerformen vereinbart. QA will etwas, das sich in einer kurzen Demo per curl zeigen lässt.
Die Checkliste unten ist, was diese Story auf dem Arbeitselement tragen könnte — keine Vorlage für jede API, sondern ein Muster: wer sie aufrufen darf, wie Erfolg aussieht, wie Fehler aussehen und wie Sie zeigen, dass sie funktioniert.
Der beste Test für jede Zeile: Kann jemand das ohne Raten demoen? Die nächste Story bekommt ihre eigene Liste — dieselbe Idee, andere Beispiele.
Acceptance Criteria — API zum Listen von Jira-Vorgängen
- Scope
- Authentifizierte Benutzer mit Browse-Berechtigung auf dem Projekt können GET /issues aufrufen
- Die Antwort ist JSON; UI-Arbeit bleibt außerhalb dieser Story
- Nur Vorgänge in Open, In Progress und Done werden zurückgegeben, sofern das Arbeitselement nichts anderes sagt
- Happy Path
- GET /issues?project=ENG liefert 200 mit Vorgangsschlüssel, Summary und Status für jede Zeile
- Query-Parameter page und pageSize funktionieren; Defaults sind auf dem Arbeitselement dokumentiert
- Die Antwort enthält die Gesamtzahl, damit der Client paginieren kann
- Fehler
- Unbekanntes Projekt liefert 404; Benutzer ohne Browse-Berechtigung erhalten 403
- Projekt ohne Vorgänge liefert 200 mit einer leeren Liste
- Ungültige page oder pageSize liefert 400 mit einem klaren Fehlerbody
- Demo
- Ein curl-Beispiel ist angehängt — jede Zeile oben lässt sich daraus demoen
- Offene Fragen sind geklärt oder geparkt, bevor die Entwicklung startet
Diese Liste gehört nur zu dieser Story. In Checklist for Jira fügen Sie solche Punkte direkt auf dem Arbeitselement hinzu, haken sie ab, wenn das Verhalten landet, und speichern eine kurze Starter-Vorlage, wenn sich die Form der Stories Ihres Teams wiederholt — mit jedes Mal neuen Beispielen.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.
Starter speichern, pro Story bearbeiten
- Checklist for Jira fügt ein Checklist-Panel in der Vorgangsansicht hinzu. Legen Sie dort Acceptance Criteria für Ihr Szenario an — nutzen Sie das Beispiel oben als Muster und füllen Sie Zeilen für Ihre Arbeit.
- Wenn Sie ein wiederverwendbares Gerüst wollen, speichern Sie die Überschriften (Scope, Happy Path, Fehler, Demo-bereit) als Projekt- oder globale Vorlage und schreiben Sie jede Zeile neu, wenn die nächste Story startet.
- Sie können Automatisierung pro Vorlage so konfigurieren, dass dieses Gerüst hinzugefügt wird, wenn eine Story erstellt wird oder Arbeit nach In Progress wechselt — oder es manuell über Add → Add from template anwenden, wenn Sie es brauchen.
- Wenn Ihr Team strikte Gates im Prozess will, setzen Sie einen Completion-Validator auf einen Workflow-Übergang.
- Punkte zurücksetzen oder aktualisieren, wenn sich der Scope verschiebt; am Ende mit Definition of Done und der QA-Testcheckliste kombinieren, wenn Tester einen Durchlauf besitzen — siehe Automatisierungsleitfaden.
Mit dem Rest des Delivery-Sets kombinieren
Halten Sie Definition of Done auf demselben Vorgang für die Ship-Leiste. Hängen Sie die QA-Testcheckliste an, wenn jemand einen strukturierten Testdurchlauf braucht. Nutzen Sie Definition of Ready in der Refinement, wenn Intake-Qualität Ihrem Team hilft. Das volle Set finden Sie im Vorlagen-Hub.
Häufige Fragen
Wem gehören Acceptance Criteria?
Produkt entwirft sie in der Regel; Engineering und QA schärfen sie. Eine Checkliste auf dem Vorgang macht dieses Hin und Her sichtbar, statt es in Kommentaren zu vergraben.
Warum mögen Engineering und QA Acceptance Criteria auf dem Vorgang?
Weil die Checkliste der Ort ist, an dem sie Anforderungen empfangen und verstehen — konkrete Beispiele, gegen die sie bauen und testen können, sichtbar neben der Arbeit statt vergraben in einer Beschreibung oder einem Slide Deck.
Können sich Acceptance Criteria ändern, nachdem die Entwicklung begonnen hat?
Das tun sie oft. Haken Sie Punkte auf dem Arbeitselement ab oder aktualisieren Sie sie, wenn sich der Scope verschiebt, und verlinken Sie die Diskussion dort, damit die Liste die Quelle der Wahrheit bleibt.
Woran erkenne ich, dass ein Kriterium gut genug ist?
Fragen Sie, wie Sie es demoen würden. Wenn niemand das Verhalten in einem kurzen Walkthrough zeigen kann, braucht die Zeile noch Detail.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.