Akzeptanzkriterien
Kurz gesagt: Akzeptanzkriterien sagen, wann eine Story fertig ist, bevor die Arbeit beginnt. Am besten funktionieren sie als Regel mit konkreten Beispielen: „kostenlos ab 50,00 €“ plus „49,99 € → 4,90 €, 50,00 € → 0,00 €“. Die Definition of Done ist das gemeinsame Maß für jede Story, die Definition of Ready dagegen eine Praxis von Teams und kein Teil des Scrum Guide.
Problem
Die Stornierung, die immer funktioniert
Die Story lautet „Als Kunde möchte ich meine Bestellung stornieren, damit ich nichts bezahle, was ich nicht mehr will.“ Der Entwickler setzt einen Button „Stornieren“ an jede Bestellung. QA prüft: Man drückt ihn, die Bestellung wird storniert. Bestanden.
Eine Woche später storniert ein Kunde eine Bestellung, die schon beim Paketdienst ist. Er bekommt sein Geld zurück, und das Paket kommt trotzdem an seine Tür. Das Lager fragt, wer entschieden hat, dass man eine versandte Bestellung stornieren kann.
Niemand hat das entschieden. Niemand hat aufgeschrieben, wann eine Stornierung erlaubt ist. Die Story hatte eine Karte und ein kleines Gespräch, aber keine Bestätigung.
Die Idee
Wann ist die Story fertig
Akzeptanzkriterien sind die Bedingungen, die eine Story erfüllen muss, um abgenommen zu werden. Sie sind das dritte C, die Bestätigung, aufgeschrieben.
Für das Stornieren einer Bestellung:
- Eine neue Bestellung kann storniert werden.
- Eine bezahlte Bestellung kann vor dem Versand storniert werden. Das Geld geht an den Kunden zurück.
- Eine versandte, zugestellte oder zurückgegebene Bestellung kann nicht storniert werden. Der Kunde sieht, warum und wie er das Produkt zurückgibt.
Drei Zeilen, und der Fehler vom Anfang wäre nicht passiert. Der Entwickler hätte gewusst, was er bauen soll, QA, was sie prüfen soll, und der Inhaber, was er abnimmt.
Die Kriterien gelten für eine Story. Sie werden vor der Arbeit geschrieben, gemeinsam: der Fachbereich, QA und der Entwickler. Danach geschrieben, beschreiben sie, was gebaut wurde, nicht, was gebraucht wurde.
Die Idee
Regel und Beispiel
Eine Regel allein genügt nicht. Zwei Menschen lesen „Die Lieferung ist ab 50 € kostenlos“ auf zwei Weisen. Deshalb gehören zu jeder Regel Beispiele mit konkreten Zahlen:
Regel: Die Lieferung ist bei einer Bestellung ab 50,00 € einschließlich kostenlos, sonst kostet sie 4,90 €.
- Ein Warenkorb von 49,99 €: Die Lieferung kostet 4,90 €.
- Ein Warenkorb von 50,00 €: Die Lieferung ist kostenlos.
Regel: Der Gutscheincode gilt nicht für reduzierte Produkte.
- Ein T-Shirt für 20,00 € und reduzierte Jeans für 40,00 €. Mit HERBST10 beträgt der Rabatt 2,00 €, nicht 6,00 €.
Ein Beispiel liest man auf eine Weise. Niemand kann es missverstehen, und wenn die Regel falsch ist, zeigt es das Beispiel: Der Inhaber schaut auf 49,99 € und sagt „nein, auch den will ich kostenlos“.
Merk dir die Form Regel und Beispiel. Im nächsten Modul wird sie zu einem Gherkin-Szenario: Es gibt das Schlüsselwort „Regel“, und darunter kommen die Beispiele als Szenarien. Hier gibt es noch keine Syntax, nur die Gewohnheit.
Genauer, für Neugierige
ISTQB CTFL v4.0.1 (Abschnitt 4.5.2) beschreibt zwei Hauptformate für Kriterien: szenarioorientiert, mit „Given / When / Then“ wie im BDD, und regelorientiert: eine Prüfliste oder eine Tabelle Eingabe → Ausgabe. Eine Regel mit Beispielen ist die Brücke zwischen beiden.
Der Gedanke, dass Beispiele die klarste Spezifikation sind, steht im Mittelpunkt des Buches „Specification by Example“ von Gojko Adzic (2011). In den meisten Quellen heißen die Beispiele, die eine Regel zeigen, Schlüsselbeispiele (key examples): nicht alle möglichen, sondern die, die einen Unterschied machen.
Die anderen Lehrpläne, denen dieser Kurs folgt, sagen dasselbe mit eigenen Worten. ISTQB CT-AcT v1.0 (Abnahmetest) wurde gemeinsam mit dem Board für Business-Analyse IQBBA geschrieben und behandelt, wie Analystin und Tester von einer Anforderung zu den Kriterien und den Abnahmetests kommen. Im BABOK v3 von IIBA sind User Stories (User Stories) und Kriterien (Acceptance and Evaluation Criteria) getrennte Techniken, und die Agile Extension to BABOK behandelt Business-Analyse in agilen Teams.
Probier es aus
Welches Kriterium funktioniert?
Die Idee
Das gute Kriterium
Ein Akzeptanzkriterium ist eine kleine Anforderung, also gelten auch hier die Eigenschaften aus der Lektion „Die gute Anforderung“. Die wichtigsten:
- Prüfbar. Es kann einen Test fehlschlagen lassen. „Korrekt“, „schnell“ und „bequem“ können das nicht.
- Über Verhalten, nicht über einen Bildschirm. „Der Code gibt 10 %“, nicht „ein grüner Button unter der Summe“. Wie es aussieht, entscheidet das Team.
- Mit den negativen Fällen. Was nicht erlaubt ist, und was der Kunde dann sieht. Das Stornieren nach dem Versand ist genau das.
- Mit der Grenze. 49,99 und 50,00 €. Der 14. und der 15. Tag. Fehler wohnen an Grenzen.
Und eine Regel zur Anzahl. Wachsen die Kriterien auf fünfzehn, ist die Story zu groß. Viele Kriterien heißen viele Regeln, und viele Regeln sind das Signal zum Teilen.
Die Idee
Definition of Done und Definition of Ready
Die Kriterien gelten für eine Story. Es gibt auch Maße, die für jede Story gelten.
Die Definition of Done ist die Liste, die das Team bei jeder Änderung erfüllt, was auch immer sie ist. Zum Beispiel:
- alle Akzeptanzkriterien sind geprüft;
- die Tests bestehen;
- eine andere Person im Team hat die Änderung geprüft;
- die Hilfeseite ist aktualisiert, wenn sich etwas Sichtbares geändert hat.
Eine Story ist fertig, wenn sie sowohl ihre eigenen Kriterien als auch die Definition of Done erfüllt.
Die Definition of Ready ist die Gegenprüfung, vor der Arbeit: Die Story hat eine Rolle und einen Nutzen, Kriterien mit Beispielen, keine offenen Fragen und passt in ein paar Tage.
Hier liegt die übliche Verwechslung. Der Scrum Guide definiert nur die Definition of Done, als Verpflichtung für jeden fertigen Teil des Produkts. Die Definition of Ready steht nicht im Scrum Guide. Sie ist eine Praxis, die viele Teams selbst eingeführt haben. Nützlich ist sie, solange sie eine Checkliste für ein Gespräch ist. Wird sie zu einer Schranke, die eine Story ohne Unterschrift nicht passieren kann, beginnt die Arbeit wieder langsam.
Genauer, für Neugierige
Der Scrum Guide (Ausgabe 2020) beschreibt die Definition of Done als die formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt verlangten Qualitätsmaße erfüllt. Zur Bereitschaft sagt er nur, dass Einträge des Product Backlog, die das Team innerhalb eines Sprints schaffen kann, als zur Auswahl bereit gelten. Eine eigene Liste namens Definition of Ready gibt es nicht.
Probier es aus
Was ist was?
Übung
Kriterien bei der Arbeit
1. Vom Bedarf zur Abnahme. Bring den Weg einer Story in die Reihenfolge.
Bring die Schritte vom Bedarf bis zur abgenommenen Story in die Reihenfolge.
Du schreibst die AkzeptanzkriterienDer Inhaber nimmt die Story abDer Inhaber nennt den BedarfDu prüfst gegen die KriterienDas Team baut die StoryIhr sprecht: Regeln, Beispiele, FragenDu schreibst die Story: Rolle, Ziel, Nutzen
Die Kriterien werden nach dem Gespräch und vor der Arbeit geschrieben. Geprüft wird gegen sie, und erst dann nimmt der Inhaber ab. Kommen die Kriterien nach der Arbeit, beschreiben sie, was gebaut wurde, nicht, was gebraucht wurde.
2. Das fehlende Beispiel. Jede Regel hat Beispiele, aber nicht die, die einen Unterschied machen.
Test