Scrum-Leitfaden: Akzeptanzkriterien formulieren, die Entwicklungsrückarbeit verhindern

In der dynamischen Umgebung von Scrum führt die Kluft zwischen dem, was Stakeholder sich vorstellen, und dem, was Entwickler bauen, oft zu kostspieliger Rückarbeit. Mehrdeutigkeit ist der Feind der Effizienz. Wenn Anforderungen unklar sind, muss das Team raten, und Raten führt zu Fehlern. Akzeptanzkriterien (AC) fungieren als verbindlicher Vertrag zwischen dem Geschäftswert und der technischen Umsetzung. Sie sind keine bloßen Vorschläge; sie bilden die Grenzen der Qualität.

Die Erstellung wirksamer Akzeptanzkriterien erfordert Präzision, Zusammenarbeit und ein tiefes Verständnis der User Story. Dieser Leitfaden erläutert die Mechanismen zur Formulierung von Kriterien, die Erwartungen klären, Mehrdeutigkeit reduzieren und sicherstellen, dass jeder gelieferte Increment tatsächlich wertvoll ist. Wir werden die strukturellen Bestandteile hochwertiger Kriterien, die damit verbundenen kooperativen Prozesse sowie die häufigen Fallen untersuchen, die das gesamte Scrum-Framework untergraben.

📉 Warum Mehrdeutigkeit Geld kostet

Entwicklungsrückarbeit ist nicht einfach nur die Behebung eines Bugs; sie beeinträchtigt die Geschwindigkeit und die Motivation. Wenn ein Entwickler eine Funktion aufgrund eines unvollständigen Verständnisses erstellt, zeigt die anschließende Überprüfung die Lücke auf. Die Korrektur erfordert, das vorherige Arbeitsergebnis zu vergessen und die korrekte Logik erneut umzusetzen. Dieser Zyklus verbraucht Zeit, die stattdessen für neue Funktionen genutzt werden könnte.

Berücksichtigen Sie die folgenden Faktoren, die zur Rückarbeit beitragen:

• Abweichende Erwartungen: Der Product Owner stellt sich einen bestimmten Ablauf vor, aber die Beschreibung fehlt an Detailgenauigkeit.
• Randfälle ignoriert: Der glückliche Pfad ist definiert, aber die Fehlerbehandlung und Grenzbedingungen werden ausgelassen.
• Technische Beschränkungen unbekannt: Die Kriterien berücksichtigen weder Leistungsgrenzen noch Sicherheitsanforderungen.
• Sich verändernder Kontext: Ohne klare Kriterien entsteht unbemerkt während der Entwicklung ein Scope Creep.

Durch die Investition von Zeit am Anfang in klare Kriterien verringern Teams die Wahrscheinlichkeit dieser Probleme. Das Ziel ist es, die Anstrengung in der Lebenszyklusphase nach links zu verlagern, wo Änderungen kostengünstiger und wirksamer sind.

🏗️ Die Struktur einer hochwertigen Akzeptanzbedingung

Nicht alle Akzeptanzkriterien sind gleich gut. Einige sind zu breit und erlauben Interpretationen. Andere sind zu spezifisch und binden das Team an eine einzelne Implementierung, die möglicherweise nicht optimal ist. Der ideale Mittelweg besteht darin, zu definieren,was das System tun muss, ohne vorzuschreiben,wie es gebaut werden muss.

Hochwertige Kriterien sollten folgende Merkmale aufweisen:

• Klar: In einfacher Sprache verfasst, die jeder im Team versteht.
• Prüfbar: Es muss eine Möglichkeit geben, zu überprüfen, ob die Bedingung erfüllt ist.
• Vollständig: Alle Szenarien abdeckend, einschließlich negativer Pfade.
• Unmissverständlich: Verwendung spezifischer Zahlen und Begriffe statt subjektiver Adjektive.

Unten ist ein Vergleich von schlechten gegenüber starken Kriterien dargestellt, um den Unterschied zu veranschaulichen.

❌ Vages Kriterium	✅ Präzises Kriterium
Das System sollte schnell sein.	Die Seite lädt sich in weniger als 2 Sekunden bei einer standardmäßigen 4G-Verbindung.
Benutzer können Dateien hochladen.	Benutzer können Dateien bis zu 10 MB im PDF- oder JPG-Format hochladen.
Die Suchfunktion funktioniert gut.	Die Suche gibt Ergebnisse innerhalb von 500 ms zurück und verarbeitet Tippfehler über unscharfe Übereinstimmung.
Stellen Sie sicher, dass die Daten sicher sind.	Passwörter werden vor der Speicherung mit bcrypt gehasht.

🔍 Techniken für Präzision

Um die Klarheit zu erreichen, die erforderlich ist, um Nacharbeit zu vermeiden, sollten Teams strukturierte Schreibtechniken einsetzen. Diese Methoden zwingen den Autor, die Logik vor der Codeerstellung durchzudenken.

1. Das Gegeben-Wenn-Dann-Format

Häufig als Gherkin-Syntax bezeichnet, strukturiert dieses Format Kriterien in drei verschiedene Teile:

• Gegeben: Der ursprüngliche Kontext oder Zustand des Systems.
• Wenn: Die Aktion oder das Ereignis, das eintritt.
• Dann: Das beobachtbare Ergebnis oder Ergebnis.

Diese Struktur ist mächtig, weil sie direkt mit automatisierten Tests übereinstimmt. Wenn Sie das Kriterium in diesem Format formulieren können, können Sie oft sofort den Testfall schreiben. Zum Beispiel:

Gegeben sich der Benutzer auf der Anmeldeseite befindet,
Wenn sie eine gültige E-Mail-Adresse und ein Passwort eingeben,
Dann werden sie zur Dashboardseite weitergeleitet.

Umgekehrt würde ein negativer Szenario folgendermaßen aussehen:

Gegeben der Benutzer befindet sich auf der Anmeldeseite,
Wennsie ein falsches Passwort eingeben,
Dannsehen sie eine Fehlermeldung und bleiben auf der Anmeldeseite.

2. Geschäftsvorschriften und Einschränkungen

Akzeptanzkriterien müssen oft spezifische Geschäftsvorschriften codieren. Dies sind nicht verhandelbare Einschränkungen, die durch die Organisation oder gesetzliche Anforderungen festgelegt werden. Seien Sie bei diesen Einschränkungen explizit.

• Finanzielle Grenzen:Transaktionen dürfen 10.000 US-Dollar ohne Genehmigung des Managers nicht überschreiten.
• Compliance:Benutzerdaten müssen gemäß lokaler Vorschriften sieben Jahre lang aufbewahrt werden.
• Leistungsfähigkeit:Das System muss 1.000 gleichzeitige Benutzer unterstützen.

3. Randfälle und Fehlerbehandlung

Der größte Teil der Nacharbeit entsteht, wenn das System unerwartet reagiert. Entwickler konzentrieren sich oft auf den glücklichen Pfad. Die Kriterien müssen explizit klären, was geschieht, wenn Dinge schief laufen.

• Was passiert, wenn die Internetverbindung während einer Übermittlung abbricht?
• Was passiert, wenn eine Datenbankabfrage abläuft?
• Was passiert, wenn das Eingabefeld Sonderzeichen erhält?

🤝 Zusammenarbeit und die Drei Freunde

Die Erstellung von Akzeptanzkriterien ist selten eine einzelne Aufgabe. Sie erfordert die Einbindung der drei zentralen Rollen, die am Wertlieferungsprozess beteiligt sind: des Product Owners, des Entwicklers und des Testers. Diese Praxis wird oft als „Drei Freunde“-Besprechung bezeichnet.

Während dieser kooperativen Sitzung überprüft das Team die Nutzergeschichte gemeinsam und entwirft die Kriterien gemeinsam. Jede Perspektive bringt die notwendige Tiefe mit:

• Product Owner:Stellt sicher, dass die Kriterien den Geschäftswert und die Nutzerbedürfnisse widerspiegeln.
• Entwickler:Identifiziert die technische Umsetzbarkeit und mögliche architektonische Auswirkungen.
• Tester:Konzentriert sich auf Randfälle, Sicherheit und die Überprüfung der Kriterien.

Diese Zusammenarbeit verhindert die häufige Falle, dass der Product Owner Kriterien formuliert, die technisch unmöglich sind, oder dass der Entwickler Kriterien schreibt, die das Geschäftsziel verfehlen. Sie schafft ein gemeinsames Verständnis, bevor ein einziger Codezeile geschrieben wird.

🔄 Akzeptanzkriterien im Vergleich zur Definition des Fertigstellungsstatus

Es ist üblich, Akzeptanzkriterien mit der Definition des Fertigstellungsstatus (DoD) zu verwechseln. Obwohl sie verwandt sind, dienen sie unterschiedlichen Zwecken. Die Unterscheidung zu verstehen, ist entscheidend für eine genaue Planung.

• Akzeptanzkriterien: Spezifisch für eine einzelne User Story. Es definiert, was diesesFeature vollständig und wertvoll für den Benutzer macht.
• Definition of Done: Gilt für alle User Stories. Es definiert die Qualitätsstandards für den gesamten Increment (z. B. Code-Review, Einheitstests bestanden, bereitgestellt in der Staging-Umgebung).

Wenn die DoD nicht erfüllt ist, ist die Story nicht abgeschlossen, unabhängig davon, ob die Akzeptanzkriterien erfüllt sind. Wenn die Akzeptanzkriterien nicht erfüllt sind, ist die Story nicht wertvoll, auch wenn die DoD erfüllt ist.

🚫 Häufige Fallen, die vermieden werden sollten

Sogar erfahrene Teams geraten in Fallen, die die Qualität ihrer Kriterien beeinträchtigen. Die Erkenntnis dieser Fallen ist der erste Schritt zur Minderung.

1. Verwendung von subjektivem Sprachgebrauch

Wörter wie „einfach“, „schnell“, „intuitiv“ oder „robust“ sind subjektiv. Was für eine Person intuitiv ist, kann für eine andere verwirrend sein. Ersetzen Sie diese durch messbare Standards.

• ❌ Die Oberfläche sollte intuitiv sein.
• ✅ Benutzer können den Checkout-Fluss in drei Klicks abschließen.

2. Fokussierung auf Implementierungsdetails

Akzeptanzkriterien sollten Verhalten beschreiben, nicht die Implementierung. Wenn Sie die Technologie festlegen, beschränken Sie die Fähigkeit des Entwicklers, die beste Lösung zu wählen.

• ❌ Das System muss ein Dropdown-Menü zur Auswahl verwenden.
• ✅ Benutzer müssen eine Option aus einer Liste von fünf auswählen.

3. Ignorieren von Nicht-Funktionalen Anforderungen

Leistungsfähigkeit, Sicherheit und Barrierefreiheit werden oft erst am Ende des Sprints berücksichtigt. Fügen Sie sie in die Kriterien ein, wenn sie für die User Story entscheidend sind.

• ✅ Die Bildergalerie muss die Tastaturnavigation unterstützen.
• ✅ Die API-Antwortzeit darf 200 ms nicht überschreiten.

4. Überlastung einer einzelnen Story

Wenn eine User Story zu viele komplexe Akzeptanzkriterien erfordert, ist sie wahrscheinlich zu groß. Teilen Sie sie in kleinere Stories auf. Große Stories sind schwerer abzuschätzen, schwerer zu testen und schwerer zu integrieren.

📊 Erfolg messen

Wie wissen Sie, ob Ihre Akzeptanzkriterien funktionieren? Sie benötigen Metriken, die Qualität und Effizienz widerspiegeln. Verfolgen Sie diese Indikatoren über die Zeit:

• Ablehnungsrate: Wie viele Stories werden während der Sprint-Review-Phase aufgrund fehlender Kriterien abgelehnt?
• Nacharbeit-Prozentsatz: Welcher Anteil des Sprints wurde damit verbracht, Probleme zu beheben, die durch die Kriterien hätten erkannt werden müssen?
• Testabdeckung: Stimmen die Akzeptanzkriterien direkt mit automatisierten Tests überein?
• Team-Geschwindigkeit: Bewegt sich das Team schneller, sobald die Kriterien klar sind?

Prüfen Sie diese Metriken in der Retrospektive. Wenn der Nacharbeit-Aufwand hoch ist, analysieren Sie die gescheiterten Kriterien. Hat das Team einen Sonderfall übersehen? War die Sprache mehrdeutig? Nutzen Sie diese Daten, um den Prozess zu verfeinern.

🛠️ Prozesskontinuierliche Verbesserung im Laufe der Zeit

Akzeptanzkriterien zu schreiben ist eine Fähigkeit, die sich durch Übung verbessert. Kein Team schafft es beim ersten Versuch perfekt. Kontinuierliche Verbesserung ist notwendig.

1. Betrachtung früherer Stories: Sehen Sie sich Stories aus früheren Sprints an. Welche haben Verwirrung gestiftet? Überarbeiten Sie die Kriterien für ähnliche Stories im aktuellen Backlog.
2. Standardisieren Sie Vorlagen: Erstellen Sie eine gemeinsame Vorlage für gängige Story-Typen (z. B. Anmeldung, Suche, Dashboard). Dadurch wird Konsistenz gewährleistet.
3. Schulen Sie das Team: Stellen Sie sicher, dass alle Teammitglieder verstehen, wie Kriterien geschrieben und überprüft werden. Führen Sie ggf. Workshops durch.
4. Fördern Sie Fragen: Fördern Sie eine Kultur, in der die Frage „Was bedeutet das?“ ermutigt wird, nicht verboten ist.

❓ Häufig gestellte Fragen

F: Können Akzeptanzkriterien während der Entwicklung geändert werden?

A: Ja, aber das sollte selten sein. Wenn sich die Kriterien erheblich ändern, könnte die Story neu geschätzt oder aufgeteilt werden müssen. Diskutieren Sie Änderungen sofort mit dem Team, um verschwendete Arbeit zu vermeiden.

F: Wer ist für die Erstellung der Kriterien verantwortlich?

A: Idealerweise verfasst der Product Owner den ersten Entwurf, aber das gesamte Team arbeitet gemeinsam an der Verbesserung. Das Team ist für die endgültige Version verantwortlich, da es die Story baut und testet.

F: Wie viele Kriterien sollte eine Story haben?

A: Es gibt keine feste Anzahl. Es hängt von der Komplexität ab. Typischerweise reichen 3 bis 7 Kriterien, um ausreichend Detail zu liefern, ohne überwältigend zu wirken. Wenn Sie mehr haben, überlegen Sie, die Story aufzuteilen.

F: Was ist, wenn ein Kriterium nicht getestet werden kann?

A: Wenn es nicht getestet werden kann, kann es auch nicht verifiziert werden. Sie müssen es umschreiben, damit es beobachtbar ist. Wenn Sie es nicht messen können, können Sie nicht wissen, ob es erledigt ist.

F: Gilt das auch für nicht-Software-Projekte?

A: Die Prinzipien gelten für jedes Projekt, das klare Anforderungen erfordert. Die Fachbegriffe können sich ändern, aber die Notwendigkeit klarer, testbarer und eindeutiger Bedingungen bleibt bestehen.

🚀 Vorwärts schauen

Die Einführung eines strengen Ansatzes für Akzeptanzkriterien ist eine Reise. Sie erfordert Disziplin und ein Engagement für Klarheit. Indem die Grenzen der Arbeit klar definiert werden, können Teams sich auf die Umsetzung konzentrieren, statt ständig Klarstellungen vorzunehmen. Diese Verschiebung verringert Reibung, verbessert die Qualität und liefert schneller Wert.

Beginnen Sie damit, Ihren nächsten Sprint-Backlog zu überprüfen. Wählen Sie eine Benutzerstory aus und überarbeiten Sie ihre Akzeptanzkriterien mit den oben genannten Techniken. Testen Sie den neuen Prozess. Messen Sie die Unterschiede. Im Laufe der Zeit wird die Reduzierung der Nacharbeit deutlich werden, und das Team wird mit größerer Sicherheit und Fluss arbeiten.

Denken Sie daran, das Ziel ist nicht Perfektion, sondern kontinuierliche Verbesserung. Jede Geschichte ist eine Gelegenheit, Ihre Definition von Wert zu verfeinern. Behalten Sie den Fokus auf dem Nutzer bei, halten Sie die Sprache präzise und halten Sie die Zusammenarbeit offen.