Wenn du ein Auto kaufst, in einem Restaurant Essen bestellst oder beim Bäcker um die Ecke deine Brötchen holst, hast du eine bestimmte Erwartung an das Endprodukt.
Stimmt deine Erwartung nicht mit der Qualität des Produkts überein, bist du im besten Fall etwas unzufrieden und im schlimmsten Fall so frustriert, dass du diesem Unternehmen den Rücken kehrst. Dies gilt es aus Sicht des Anbieters unter allen Umständen zu vermeiden. Deshalb wird der Qualitätsstandard, welchen Unternehmen an ihre Produkte setzen, potenziellen Käufern und Kunden klar kommuniziert.
Für Softwareprodukte ist das nicht anders. Die Performance der Anwendung, die Verfügbarkeit des Kundensupports und die Erreichbarkeit der Services sind Qualitätsmerkmale, die jeder Kunde kennen sollte.
Die Definition of Done in Scrum
In Scrum bezeichnen wir die Qualitätskriterien, die die Erwartung der Kunden und Nutzer definieren, als die Definition of Done:
„Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“ – Scrum Guide
Die Definition of Done sollte also die Qualität beschreiben, die den Erwartungen der Kunden oder der Nutzer und letztlich des Unternehmens entspricht.
Ein Beispiel für eine Definition of Done
Kehren wir zum Beispiel von der Bäckerei um die Ecke zurück, dann könnte eine exemplarische Definition of Done wie folgt beschrieben sein:
- Alle verwendeten Backzutaten waren frisch.
- Die Backstube war zu jeder Zeit der Zubereitung sauber und aufgeräumt.
- Jeder Bäcker hat sich vor dem Kontakt mit Lebensmitteln die Hände gewaschen und trägt ein Haarnetz.
- Die Backwaren wurden nach dem Backen visuell darauf geprüft, ob sie den Standards entsprechen.
- Eine Backware jeder Charge hat einen Geschmackstest bestanden, bevor die Charge in den Verkauf kommt.
Was haben alle diese Punkte der Definition of Done gemeinsam?
Sie beschreiben den Qualitätszustand des Endprodukts, ohne die Merkmale der Backwaren zu beschränken! In Softwareentwicklungssprache ausgedrückt: Die Elemente der Definition of Done beschränken nicht den Umfang von Anforderungen an das Produkt. Dies ist ein häufiger Fehler, welchen ich auch bei meiner Arbeit mit erfahren Produktentwicklungsteams noch häufig sehe. Dass das Baguette zwischen 56 und 66 cm lang sein muss und einen Durchmesser von 6 bis 8 cm besitzen sollte, beschreibt den Umfang der Anforderung und keinen Qualitätsstandard.
Den Umfang eines Eintrags im Product Backlog können wir etwa mit Akzeptanzkriterien festhalten.
Was sind Akzeptanzkriterien
Akzeptanzkriterien sind eine Reihe von Aussagen, die die Bedingungen beschreiben, die eine Arbeit erfüllen muss, um von Nutzern, Kunden oder anderen Stakeholdern akzeptiert zu werden. Akzeptanzkriterien erhöhen die Transparenz darüber, was erforderlich ist, um eine Arbeit zur Zufriedenheit aller Beteiligten abzuschließen.
Ein Beispiel für Akzeptanzkriterien
Betrachten wir hierzu in unserem Beispiel der Bäckerei die zwei Einträge „Baguette“ und „Laugenstange“ im Product Backlog. Dann könnten Akzeptanzkriterien wie folgt aussehen:
Product-Backlog-Eintrag 1: Baguette mit Akzeptanzkriterien
- mindestens 65 cm lang und 6 cm im Durchmesser
- 20 Minuten lang bei 220 Grad gebacken
- goldbraun auf der ganzen Oberfläche nach dem Backen
Product-Backlog-Eintrag 2: Laugenstange mit Akzeptanzkriterien
- mindestens 15 cm lang und 3 cm hoch
- 15 Minuten lang bei 200 Grad gebacken
- die Lauge bedeckt mindestens 80 % der Oberseite des Gebäcks
Mit dieser Frage unterscheidest du Akzeptanzkriterien von der Definition of Done
Wenn wir entscheiden müssen, ob etwas Bestandteil der Definition of Done sein sollte oder doch eher ein Akzeptanzkriterium ist, dann hilft uns folgende Frage:
Beschränkt es den Umfang der Arbeit oder beschreibt es die Qualität der Arbeit?
Ein abschließender Test
Softwareentwicklung ist komplexer und nicht so einfach zu beschreiben wie das Backen.
Aus meiner eigenen Erfahrung mit der Arbeit mit Softwareentwicklungsteams weiß ich, dass es manchmal schwierig sein kann, zu entscheiden, ob etwas den Umfang der Arbeit beschreibt oder eher eine Qualität des Produkts ausdrückt. Deshalb verrate ich dir noch mein Geheimnis, wie ich im Zweifel entscheide, ob eine Aussage Teil der Definition of Done sein sollte oder nicht. Ich unterziehe sie folgendem Test:
Gilt diese Aussage wirklich für alle Einträge des Product Backlogs – ohne Ausnahme?
Lautet die Antwort „Ja“, dann sollte sie Bestandteil der Definition of Done sein. Falls die Antwort „Nein“ ist, dann gilt die Aussage nur für ausgewählte Einträge im Product Backlog und sollte dementsprechend ein Akzeptanzkriterium für diese darstellen.
Betrachten wir dazu folgendes Beispiel einer Definition of Done und eines Eintrags im Product Backlog in Form einer User Story:
Definition of Done:
- es funktioniert und ist in Produktion
- Code-Review und Code-Analyse bestanden
- durch Tests (Unit, Integration, Regression und Last) abgesichert und hat alle Tests bestanden
- kein augenscheinliches Fehlverhalten
- alle Anzeigetexte sind internationalisiert
- API und Designentscheidungen sind dokumentiert
User Story: Laufzeit vorhersagen
Als Gelegenheitsläufer möchte ich in der Lage sein, die Laufzeit für eine neue Strecke zu prognostizieren, damit ich mein Training besser planen kann. Die Prognose soll auf meinen früheren Laufzeiten basieren.
Betrachten wir etwa die Aussage „kürzeste erlaubte Eingabe für die Distanz ist 1 km“ und unterziehen sie dem Test, ob sie für jeden Eintrag des Product Backlogs gelten muss, so sehen wir, dass es sich hierbei um ein Akzeptanzkriterium handelt.
Wie unterscheidest du zwischen Akzeptanzkriterien und der Definition of Done? Schreibe es gern in die Kommentare!