Ein Schnellstart-Leitfaden zu Akzeptanzkriterien für User Stories

In diesem Beitrag erfahrt ihr, wie ihr euer Team ganz einfach für diese Praxis gewinnt: indem ihr während der Refinement-Diskussionen Notizen macht.

Doch zunächst schauen wir uns an, warum Akzeptanzkriterien wichtig sind. Ihr könnt aber auch direkt zur Methode zum Notizenmachen am Ende springen.

Was sind Akzeptanzkriterien?

Agile Teams arbeiten mit einem Backlog. Die Einträge im Backlog können im User-Story-Format formuliert sein. Eine User Story ist eine kurze Beschreibung der Arbeit und erläutert:

• Wer die Ergebnisse der Arbeit benötigt

• Welches Problem gelöst werden soll

• Warum es gelöst werden muss

Dieses „Wer & Was & Warum“ wird manchmal als Cohn-Story-Format bezeichnet.

Arbeitseinträge als User Stories zu formulieren, ist lediglich ein Hilfsmittel zum Nachdenken. Es ist nicht verpflichtend. Nutzt es, wenn ein klares Problem eines Systemnutzers gelöst werden soll. User Stories helfen dem Team, das zu lösende Problem zu besprechen und ein gemeinsames Verständnis dafür zu entwickeln.

Warum User Stories um Akzeptanzkriterien ergänzen?

Ein Hauptgrund für User Stories ist, eine gemeinsame Sprache zwischen Fachbereich und Entwicklern zu schaffen. User Stories beschreiben den Bedarf, also das Problem, so, dass alle ihn verstehen und darüber sprechen können sollten.

User Stories richten die Diskussion auf das Verständnis des Problems aus. Das Team kann vermeiden, zu früh zu tief in technische Diskussionen einzusteigen, die nicht technische Stakeholder aus dem Fachbereich ausschließen könnten. Mit einem gemeinsamen Verständnis des Bedarfs kann das Team besser definieren, welche Art von Lösung nötig ist.

Eine User Story besteht aus drei separaten Teilen:

1. Titel

2. Beschreibung (Wer, Was und Warum)

3. Liste der Akzeptanzkriterien

Titel und Beschreibung legen fest, warum das Problem gelöst werden muss und wer davon profitiert.

Die Akzeptanzkriterien definieren jedoch das Was der Story.

Ohne Akzeptanzkriterien besteht das Risiko, dass ihr:

• etwas Notwendiges nicht implementiert – und etwas als Done bezeichnet, nur um später festzustellen, dass es überarbeitet werden muss

• etwas implementiert, das nicht benötigt wird

• kein vollständig gemeinsames Verständnis davon habt, was benötigt wird

• den Aufwand ungenau schätzt

All diese Risiken können zu Verschwendung führen. Euer Team muss möglicherweise etwas mehrfach überarbeiten, um es richtig umzusetzen, oder die Arbeit ist zu groß, um sie innerhalb eines Sprints abzuschließen.

Vermeidet die Frage: „Warum dauert das so lange?“

Oft fragt sich der Product Owner, warum die Entwicklung so lange dauert. Das Feature sollte doch einfach umzusetzen sein. Die ursprüngliche Aufwandsschätzung lag bei ein oder zwei Wochen. Inzwischen ist mehr als ein Monat vergangen. Was ist los?

Für das Entwicklungsteam ist es allzu leicht, zu viele Dinge hinzuzufügen und alle Eventualitäten abdecken zu wollen. Entwickler neigen manchmal dazu, eine überdimensionierte Lösung zu entwickeln, obwohl bei der Überprüfung ein viel einfacherer Ansatz ausgereicht hätte. Diese Verschwendung von Aufwand und Zeit hätte sich durch die Diskussion von Akzeptanzkriterien verhindern lassen – sie eignen sich hervorragend, um zu entscheiden, was nicht benötigt wird.

Ein Beispiel: Der Teufel steckt im Detail

Ein weiteres häufiges Problem, wenn Akzeptanzkriterien nicht genutzt werden: Features werden entwickelt, ohne alle tatsächlich erforderlichen Aspekte vollständig zu berücksichtigen. Sehen wir uns ein Beispiel an.

Beispiel für eine User Story: Passwort ändern

Ein Nutzer:
Ich möchte mein Passwort ändern, damit ich das System nutzen kann.

Diese User Story beschreibt ein Problem: Das System sollte Nutzern eine Möglichkeit bieten, ihr Passwort zu ändern. Eine Lösung könnte eine Option zum „Passwort ändern“ an einer geeigneten Stelle sein, gefolgt von einer Ansicht oder einem Popup, in dem Nutzer ihr Passwort ändern können. 

Einfach, oder? Sollen wir mit der Umsetzung beginnen oder den Aufwand dafür schätzen?

Akzeptanzkriterien zeigen die tatsächliche Komplexität

Lassen Sie uns einige mögliche Akzeptanzkriterien besprechen. Folgende Punkte könnten berücksichtigt werden:

• Das Passwort ist mindestens 8 Zeichen lang

• Das Passwort muss mindestens ein Sonderzeichen enthalten

  • Liste der geprüften Sonderzeichen 

• Das Passwort muss mindestens einen Klein- und einen Großbuchstaben enthalten

• Das Passwort muss in zwei separate Felder eingegeben werden

• Beide Passwortfelder müssen übereinstimmen, bevor eine Registrierung möglich ist

• Dem Endnutzer wird angezeigt, wenn das Passwort nicht sicher genug ist

• Die Sicherheitsanzeige soll sich nach jeder Änderung im Passwortfeld aktualisieren

• Dem Nutzer wird mitgeteilt, warum eine Registrierung nicht möglich ist 

  • Das Passwort muss mindestens 8 Zeichen lang sein 

  • Das Passwort ist nicht sicher genug: Fügen Sie Sonderzeichen oder Zahlen hinzu

  • Bitte füllen Sie alle Pflichtfelder aus – [Feld mit fehlenden Informationen]

• Eine Registrierung ist nur möglich, wenn das Passwort sicher genug ist 

• Eine Registrierung ist nur möglich, wenn alle anderen Pflichtfelder ausgefüllt sind

• Pflichtfelder sind eindeutig gekennzeichnet

Ohne die Akzeptanzkriterien zu besprechen, könnte eine einfache Story wie in unserem Beispiel zwar umgesetzt werden, doch die Logik hinter der Seite wäre noch nicht fertig. Die offenen Punkte würden später zutage treten, und das Team müsste zur Seite zurückkehren, um sie für den Nutzer nutzbar und ansprechend zu gestalten.

Schätzt den Aufwand erst, nachdem ihr die Akzeptanzkriterien aufgelistet habt

Indem das Team genau bespricht, was erledigt werden muss, kann es ein gemeinsames Verständnis entwickeln. Erst danach solltet ihr den Aufwand schätzen. Ohne Akzeptanzkriterien könnte die Erstellung der Seite auf wenige Stunden oder einen Story Point geschätzt werden. Mit allen Akzeptanzkriterien kann sich die Schätzung auf einige Tage oder 3–5 Story Points erhöhen.

Die wichtigsten Vorteile von Akzeptanzkriterien

Die wichtigsten Vorteile von Akzeptanzkriterien sind:

• Ein gemeinsames Verständnis dessen, was benötigt wird

• Genauere Aufwandsschätzungen

• Genauere Velocity-Schätzungen

• Bessere Verbindlichkeit für den Sprint

• Zu große Stories leichter erkennen

• Zu große Stories leichter in kleinere Stories aufteilen

So startet ihr einfach mit Akzeptanzkriterien: Dokumentiert die Diskussion

Diese Methode ist für Teams gedacht, die bislang keine Erfahrung mit Akzeptanzkriterien haben.

Für diesen Prozess braucht ihr jemanden, der Notizen macht oder die Rolle eines Protokollführers übernimmt. Wenn ihr einen Scrum Master habt, kann er diese Aufgabe übernehmen.

1. Öffnet die User Story so, dass sie jeder sehen kann (sehr wichtig – schließlich soll jeder sofort sehen, welche Art von Notizen gemacht wird).

2. Beginnt, Fragen zu stellen sowie Kommentare und Antworten einzubringen: Was bedeutet diese Story?

3. Der Protokollführer interpretiert die Fragen und Kommentare und notiert sie sofort als Stichpunkte unter der Story-Beschreibung. HINWEIS: An diesem Punkt ist es wichtig, dass der Protokollführer alle Kommentare und Fragen in die Beschreibung aufnimmt, ohne auf eine Bestätigung oder Entscheidung zu warten. Ziel ist es, die Diskussion zu dokumentieren. Fahrt damit einige Minuten fort.

4. Nach einigen Minuten oder wenn die Diskussion abebbt, schaut euch die Liste der Stichpunkte an. Die aufgeführten Punkte sind potenzielle Akzeptanzkriterien. Im nächsten Schritt prüft ihr, ob jemand einem der aufgeführten Punkte widerspricht. Falls ja, konzentriert die Diskussion auf dieses Thema.

5. Klären wir abschließend einige Fragen:

   1. Werden all diese Punkte benötigt?

   2. Gibt es Punkte, die sich zu widersprechen scheinen?

   3. Fehlt etwas Offensichtliches?

   4. Haben wir zu viele Akzeptanzkriterien? In der Regel deutet eine Anzahl von mehr als 10 darauf hin, dass die Story möglicherweise in zwei kleinere Stories aufgeteilt werden kann.

Macht euer Team zunächst mit Akzeptanzkriterien vertrauter – entwickelt die Praxis später weiter

Ihr könnt es ganz einfach zusammenfassen: Macht einfach Notizen und dokumentiert die Diskussion. Kümmert euch nicht um formale Aspekte wie „Akzeptanzkriterien als Frage formulieren“. Das kann später kommen, wenn ihr möchtet.

Der Mehrwert dokumentierter Stichpunkte und ein Team, das sie selbstverständlich zu jeder Story hinzufügt, sind wichtiger als die Einhaltung solcher formalen Regeln.