So schreiben Sie Akzeptanzkriterien: Beispiele und Best Practices

Hier bei Mobindustry arbeiten wir mit einem agilen Ansatz. Das heißt, wir verwenden agile Komponenten wie User Stories und Akzeptanzkriterien. Leistungsstarke Teams und Organisationen haben diese Komponenten in ihren Produkt-Backlogs und wissen, wie sie sie erstellen und effektiv nutzen können.

Wenn es in Ihrem Produktrückstand an User Stories und Akzeptanzkriterien mangelt — oder wenn diese nicht klar definiert sind-riskieren Sie, dass Ihre Erwartungen nicht mit der Realität übereinstimmen., User Stories und Akzeptanzkriterien sind dafür verantwortlich, darzustellen, wie der Endbenutzer Ihre App verwendet und wie Ihr Entwicklungsteam jede Entwicklungsaufgabe ausführen soll. Wenn wir mit der Arbeit an einem neuen Produkt beginnen, arbeitet unser Team mit dem Kunden zusammen, um User Stories zu definieren.

Eine User Story ist eine kurze, einfache Beschreibung einer Produktfunktion aus der Perspektive einer Person, die diese Funktion verwenden möchte. User Stories werden verwendet, um den Produktrückstand in einem agilen Entwicklungsworkflow zu definieren.,

Der Product Backlog ist im Wesentlichen eine Sammlung von User Stories, die die Funktionsspezifikation und die Entwicklung von Funktionen für ein bestimmtes Produkt oder eine bestimmte Dienstleistung informiert. User Stories bestehen aus drei Teilen: einer Persona des Benutzers, für den die Story geschrieben wird, einer Beschreibung des Features, das der Benutzer benötigt, und einer Erklärung des Bedarfs, den das Feature erfüllt.

So schreiben Sie eine User Story:

Als (Benutzer) möchte ich eine (Funktion), damit ich (einen Bedarf befriedigen) kann.

Schauen wir uns an, wie eine User Story aussehen könnte., Wir nehmen Airbnb als Beispiel. Stellen wir uns vor, wie eine typische User Story für ein Produkt wie Airbnb aussehen könnte.

“ Als Benutzer möchte ich nach einem Ziel suchen, damit ich eine Unterkunft in einer fremden Stadt buchen kann.“

Definition von Akzeptanzkriterien

Jetzt müssen wir sicherstellen, dass User Stories korrekt abgeschlossen sind und den Anforderungen des Kunden entsprechen.

Akzeptanzkriterien sind die Bedingungen, die ein Softwareprodukt erfüllen muss, um von einem Benutzer, Kunden oder im Falle einer Funktionalität auf Systemebene vom verbrauchenden System akzeptiert zu werden.,

Akzeptanzkriterien sind eine Reihe von Anweisungen mit jeweils einem eindeutigen Pass/Fail-Ergebnis, die gemessen werden können und sowohl funktionale als auch nicht funktionale Anforderungen angeben.

Das Schreiben von Akzeptanzkriterien ist nicht nur wichtig, um festzustellen, was der Kunde vom Produkt erwartet, sondern auch für den Entwicklungsprozess. Natürlich sehen verschiedene Menschen das gleiche Problem aus verschiedenen Blickwinkeln. Gut definierte Akzeptanzkriterien bieten eine einheitliche Sicht auf die Funktionalität, die Sie implementieren möchten.,

Jeder sollte in der Lage sein, zu einem Scrum-Board zu gehen, einen Produkt-Backlog-Artikel zu ergattern, die Akzeptanzkriterien zu lesen und alles klar zu sehen, was für diesen bestimmten Artikel abgeschlossen werden muss, um in die Spalte Fertig verschoben zu werden. Akzeptanzkriterien sagen Ihnen, was für einen bestimmten Teil eines Produkts getan werden muss, um fertig zu werden.

Warum brauchen wir Akzeptanzkriterien?,

• Grenzen definieren. Akzeptanzkriterien helfen dem Entwicklungsteam, die Grenzen einer User Story zu definieren. Sie dienen als eine form der Bestätigung, dass die app wie erwartet funktioniert, was bedeutet, dass die user story abgeschlossen ist.
• Konsens. Akzeptanzkriterien ermöglichen es dem Entwicklungsteam, sich auf derselben Seite wie der Kunde zu befinden. Sie informieren das Entwicklungsteam genau darüber, welche Bedingungen erfüllt sein müssen und stellen sicher, dass der Kunde weiß, was er von der Anwendung erwarten kann.
• Optimierung der Abnahmetests., Akzeptanzkriterien sind die Grundlage für User Story-Akzeptanztests. Jedes Akzeptanzkriterium sollte unabhängig getestet werden und klare Szenarien für Erfolg oder Misserfolg aufweisen.
• Planung und Schätzung. Akzeptanzkriterien ermöglichen es Ihnen, User Storys über Aufgaben zu verteilen, damit sie ordnungsgemäß bewertet und geplant werden.
• Beschreibung negativer Szenarien. Akzeptanzkriterien können erfordern, dass das System ein schwaches Passwort identifiziert und beispielsweise verhindert, dass ein Benutzer fortfährt., Die Eingabe eines falschen Kennwortformats ist ein Beispiel für ein negatives Szenario, in dem ein Benutzer falsche Daten eingibt oder sich unerwartet verhält. Akzeptanzkriterien identifizieren diese Szenarien und erklären, wie das System darauf reagieren soll.

Wer schreibt Akzeptanzkriterien?,

Das Schreiben von Akzeptanzkriterien hilft, ein gemeinsames Verständnis zwischen dem Produktinhaber und dem Entwicklungsteam hinsichtlich der Lösung des Kundenproblems oder der Erstellung von Produktfähigkeiten herzustellen. Da sich die Akzeptanzkriterien auf den Kunden und das Team beziehen, sollten sie entweder vom Kunden oder einem Teammitglied geschrieben werden.

Bei Mobindustry schreiben unsere Business Analysten alle Akzeptanzkriterien für User Stories. Business-Analysten verstehen die Bedürfnisse des Kunden und was Entwickler wissen müssen, um die Projektanforderungen zu erfüllen.,

Akzeptanzkriterien werden vor Projektbeginn dokumentiert und bestätigt, da sich das Team und der Kunde darauf einigen müssen, welche Ergebnisse den Anforderungen des Kunden entsprechen.

Beispiele für User Stories mit Akzeptanzkriterien

Nachdem Sie nun genau verstanden haben, was User Stories und Akzeptanzkriterien sind, schauen wir uns einige Beispiele an.,

Beispiel 1

User Story: Als Benutzer möchte ich mich im Service registrieren können, damit ich online einkaufen kann.

Akzeptanzkriterien:

• Benutzer können ein Formular nur senden, indem sie alle erforderlichen Felder ausfüllen.
• Die vom Benutzer bereitgestellte E-Mail darf nicht von einem kostenlosen E-Mail-Dienst bereitgestellt werden.
• Einreichungen von derselben IP können nur dreimal innerhalb von 30 Minuten erfolgen.
• Benutzer erhalten nach erfolgreicher Registrierung Benachrichtigungs-E-Mails.,

Beispiel 2

User story: Als Benutzer kann ich sofort nach Erhalt auf eine Benachrichtigung auf meinem Gerät zugreifen.

Akzeptanzkriterien:

• Das Wischen / Antippen einer Benachrichtigung führt den Benutzer direkt zur Nachricht.
• Ansicht zeigt Konversation — wenn die neue Nachricht eine Antwort war, wird sie über dem Original angezeigt.
• Die Anzahl der Nachrichten wird aktualisiert.
• Nach der Anzeige wird eine Meldung als gelesen markiert.

7 Tipps zum Schreiben guter Akzeptanzkriterien

Akzeptanzkriterien sind nicht einfach zu schreiben., Trotz des einfachen Formats ist das Schreiben des Textes eine Herausforderung. Hier sind sieben Tipps, mit denen Sie häufige Fehler beim Schreiben von Akzeptanzkriterien vermeiden oder Kriterien überprüfen können, die von einem Mitglied Ihres Teams verfasst wurden.

• Dokumentieren Sie Kriterien, bevor der Entwicklungsprozess beginnt. Auf diese Weise erfasst das Team eher alle Bedürfnisse des Kunden im Voraus. Zunächst reicht es aus, Kriterien für eine kleine Anzahl von User Stories festzulegen, um Backlogs für zwei Sprints abzuschließen. Die dokumentierten Abnahmekriterien werden dann von Entwicklern zur Planung des technischen Prozesses verwendet.,
• Machen Sie die Akzeptanzkriterien nicht zu eng. Zu spezifische Akzeptanzkriterien lassen Entwicklern wenig Handlungsspielraum. Um dies zu vermeiden, denken Sie daran, dass Akzeptanzkriterien eine Absichtserklärung und keine endgültige Entscheidung sein sollten. Darüber hinaus berücksichtigen enge Akzeptanzkriterien möglicherweise nicht alle Benutzeraktionen.
• Halten Sie Ihre Kriterien erreichbar. Effektive Akzeptanzkriterien definieren ein angemessenes Minimum an Funktionalität, die Sie bereitstellen können. Wenn Sie jedoch weiterhin alle kleinen Details beschreiben, besteht die Gefahr, dass Ihr Team bei Hunderten kleiner Aufgaben stecken bleibt.,
• Vermeiden Sie zu breite Akzeptanzkriterien. Breite Akzeptanzkriterien machen eine User Story vage. Effektive Akzeptanzkriterien müssen den Umfang der Arbeit umreißen, damit Entwickler ihre Bemühungen richtig planen und abschätzen können.
• Vermeiden Sie technische Details. Akzeptanzkriterien sollten im Klartext geschrieben werden. Ihre Stakeholder und Manager haben möglicherweise keinen technischen Hintergrund, daher werden die Kriterien durch die Verwendung einfacher Sprache für alle verständlich.
• Konsens erreichen., Das gleiche Problem kann je nach Sichtweise von Teammitgliedern und Stakeholdern auf unterschiedliche Weise gelöst werden. Stellen Sie sicher, dass Sie Stakeholdern und Teammitgliedern Ihre Akzeptanzkriterien mitteilen und eine gegenseitige Vereinbarung treffen.
• Schreiben testable akzeptanz kriterien. Dies gibt Testern die Möglichkeit, sicherzustellen, dass alle Anforderungen erfüllt sind, und ermöglicht Entwicklern zu wissen, ob die User Story vollständig ist.,

So schreiben Sie Akzeptanzkriterien

Hier sind fünf allgemeine Regeln, die Ihnen helfen, Probleme mit dem Wortlaut der Akzeptanzkriterien zu lösen. Mit diesen Regeln können Sie wertvolle Zeit sparen und ein Verständnis zwischen dem Product Owner und dem Entwicklungsteam herstellen.

Regel # 1: Vermeiden Sie „nicht“

„Nicht“ bedeutet „auf keinen Fall“, und daher reicht keine Zeit aus, um die Einhaltung einer solchen Bedingung zu überprüfen., Wenn Sie die Anforderung umschreiben, ohne „nicht“ zu verwenden, wird sie klarer und vor allem überprüfbar.

Beispiel:

User Story

Nicht: Als Benutzer möchte ich mein Passwort nicht jedes Mal eingeben müssen, wenn ich auf mein Konto zugreife.
Do: Als Benutzer möchte ich, dass mein Passwort gespeichert und automatisch ausgefüllt wird, damit ich auf mein Konto zugreifen kann, ohne mein Passwort erneut einzugeben.

Akzeptanzkriterien

Nicht: Das System darf nicht ausfallen.
Do: Das System sollte eine Verfügbarkeit von nicht weniger als 90% haben.,

Ausnahme

Sie können „nicht“ in Akzeptanzkriterien verwenden, um einen logischen Einwand einzuführen, z. B. „Das Anmeldeformular sollte nicht rot sein.“In den meisten Fällen gilt dies für nicht funktionale Anforderungen. In diesem Beispiel formulieren wir eine Einschränkung, die leicht überprüft werden kann, wenn der Rottonbereich klar definiert ist (z. B. im RGB-Format angegeben).,

Regel #2: Verwenden Sie active voice

Active voice ist, wenn das Subjekt in einem Satz der Ausführende der Aktion ist. Wenn die für die Ausführung der Aktion verantwortliche Stelle nicht klar angegeben ist, ist unklar, wer oder was die Aktion ausführen soll, und es wird schwieriger für Sie zu überprüfen, ob eine Anforderung erfüllt ist.,

Beispiel:

User Story

Nicht: Als Online-Shopper möchte ich, dass Filter angewendet werden, damit ich finden kann, was ich will.
Do: Als Benutzer möchte ich Suchfilter anwenden, damit ich Elemente finden kann.

Abnahmekriterien

Nicht: Die Identität des Kunden sollte bestätigt werden. (Es ist unklar, wer oder was für die Bestätigung der Identität des Kunden verantwortlich ist.)
Do: Das Accounting_System sollte die Customer_Indentity bestätigen. (Beachten Sie, dass die Definitionen der Begriffe „Accounting_System“ und „Customer_Indentity“ dem Glossar hinzugefügt werden sollten.,)

Regel #3: Vermeiden Sie die Verwendung von Pronomen (insbesondere undefinierten)

Verwenden Sie Substantive anstelle von Pronomen, wenn Sie auf Elemente verweisen, auf die in anderen Anforderungen verwiesen wird. Pronomen sollten vermieden werden, da sie Mehrdeutigkeit hervorrufen können.,

Dies ist besonders wichtig, wenn Akzeptanzkriterien in Anforderungsmanagementtools (wie Jira) als separate Anweisungen gespeichert werden, die nicht unbedingt organisiert sind. Verwenden Sie immer Substantive anstelle von Pronomen und Sie werden dieses Problem vermeiden.

Beispiel:

User Story

Nicht: Als Site-Mitglied möchte ich Informationen über mich selbst austauschen, damit andere sie sehen können.
Do: Als Site-Mitglied möchte ich eine Profilbeschreibung hinzufügen, damit andere etwas über mich erfahren können.

Akzeptanzkriterien

Nicht: Der Controller sollte dem Fahrer die Reiseroute für den Tag senden., Es sollte mindestens 8 Stunden vor der Schicht geliefert werden.
Do: Die Steuerung sollte die Driver_Itinerary für den Tag an den Fahrer mindestens 8 Stunden vor dem Driver_Shift senden.

Regel # 4: Vermeiden Sie Konjunktionen

Konjunktionen sind Wörter und Phrasen wie „und“, „oder“, „aber“ und „sowie“, die einfache Sätze zu komplexen kombinieren., Ihre Verwendung in Anforderungen ist in der Regel ein Zeichen dafür, dass eine Anforderung in mehrere separate Anforderungen unterteilt werden kann.

Beispiel:

User Story

Nicht: Als UI-Designer möchte ich ein Problem erstellen und anzeigen, damit ich weiß, was ich testen soll.
Do: Als UI-Designer möchte ich ein Problem erstellen, damit ich weiß, was ich testen soll. / Als UI-Designer möchte ich ein Problem anzeigen, damit ich weiß, was ich testen soll.

Akzeptanzkriterien

Nicht: Dem Benutzer sollte entweder vertraut oder nicht vertraut werden.
Do: Das Security_System sollte jeden Benutzer als Vertrauenswürdig oder Not_Trusted kategorisieren.,

Exception

“ Und „“ oder „und“ nicht “ können verwendet werden, um logische Bedingungen zu beschreiben und Qualifikationsmerkmale hinzuzufügen.

Regel #5: Vermeiden Sie unerreichbare Absolute

Ein Absolutes (z. B. 100% Verfügbarkeit) ist unerreichbar. Überlegen Sie, wie Sie den Indikator überprüfen können: Kann nachgewiesen werden, dass die Systemverfügbarkeit genau 100% beträgt?, Und selbst wenn ein solches System geschaffen werden könnte, können Sie es sich leisten?

Vermeiden Sie die Wörter „alle“, „immer“ und „nie“, da die Überprüfung solcher absoluten Anforderungen eine unendliche Anzahl von Tests erfordert.

Beispiel:

User Story

Nicht: Als Reisender möchte ich wissen, dass mein genauer Standort in Echtzeit aktualisiert wird, damit ich mich nicht verirre. („Echtzeit“ kann auf verschiedene Arten interpretiert werden. Zum Beispiel kann es als absolutes (das Fehlen einer Verzögerung) angesehen werden, das nicht erreicht werden kann und das nicht überprüfbar ist.,)
Do: Als Reisender möchte ich meinen genauen Standort kennen, der jede Sekunde aktualisiert wird, damit ich mich nicht verirre.

Akzeptanzkriterien

Nicht: Das System sollte zu 100% verfügbar sein. (100% ist ein absolutes, das nicht erreicht und nicht verifiziert werden kann.)
Do: Das System sollte eine Verfügbarkeit von mindestens 98% haben.

Kurze Zusammenfassung der Akzeptanzkriterien

Wir hoffen, dass dieser Artikel die Welt der Akzeptanzkriterien und User Stories beleuchtet hat., Hier sind die wichtigsten Takeaways:

• Akzeptanzkriterien sind die Bedingungen, die ein Softwareprodukt erfüllen muss, um von einem Benutzer, Kunden oder im Falle einer Funktionalität auf Systemebene vom verbrauchenden System akzeptiert zu werden.
• Die Abnahmekriterien sollten vor Projektbeginn dokumentiert und abgeschlossen werden, da das Team und der Kunde sich darauf einigen müssen, welche Ergebnisse den Anforderungen des Kunden entsprechen.
• Denken Sie daran, dass Akzeptanzkriterien eine Absichtserklärung und keine endgültige Entscheidung sein sollten.
• Effektive Akzeptanzkriterien definieren ein angemessenes Minimum an Funktionalität.,
• Gute Akzeptanzkriterien müssen den Umfang der Arbeit umreißen, damit Entwickler ihre Bemühungen richtig planen und abschätzen können.
• Akzeptanzkriterien sollten im Klartext geschrieben werden.
• Stellen Sie sicher, dass Sie Stakeholdern und Teammitgliedern Ihre Akzeptanzkriterien mitteilen und eine gegenseitige Vereinbarung treffen.
• Vermeiden Sie beim Schreiben von Akzeptanzkriterien die Verwendung von „Nicht“ – Konjunktionen und unerreichbaren Absoluten. Formulieren Sie Sätze mit aktiver Stimme.,

Wenn Sie Akzeptanzkriterien und User Stories für Ihre mobile App erstellen möchten oder Fragen zu diesem Thema haben, wenden Sie sich für eine kostenlose Beratung an Mobindustry.