Die Akzeptanzkriterien für die User Story mögen einfach zu bestimmen sein. Bei der Erstellung digitaler Produkte machen Kommunikationsfragen jedoch einen erheblichen Teil der auftretenden Probleme aus.
Vor allem, wenn es darum geht, die Anforderungen zu erfüllen und festzustellen, ob ein bestimmter Teil der Arbeit oder der Funktionalität abgeschlossen ist.
Um Chaos, Missverständnisse und Streitigkeiten zu vermeiden, müssen Sie Informationen, Ideen, Werte, Konzepte und Pläne so klar wie möglich austauschen.
Ihre Erwartungen an mobile Anwendungen, Webanwendungen oder andere Software zu formulieren, ist ein Problem.
Ein weiterer Punkt sind klare Akzeptanzkriterien, die wesentlich dazu beitragen, die Erwartungen der Kunden/Nutzer an ein digitales Produkt genau und umfassend zu bestimmen.
In agilen Methoden spielen die Akzeptanzkriterien der User Story eine wesentliche Rolle. Und es ist notwendig, ihnen ausreichend Zeit zu widmen, um eine wesentlich höhere Reibungslosigkeit, Produktivität und Genauigkeit der Arbeit zu gewährleisten.
Denken Sie daran, dass zu weit gefasste und zu abstrakte Zulassungskriterien einfach nutzlos sind. User Storys und Akzeptanzkriterien ermöglichen es also, allgemeinen Erwartungen konkrete Formen zu geben, z.B. wir wollen, dass ein Produkt toll und messbar ist.
Was ist eine User Story? Wie schreibt man eine User Story? Welche Rolle spielt die User Story in der agilen Methodik?
Wie bestimmt und erstellt man Akzeptanzkriterien? Was ist die Definition of Done?
Wenn Sie wissen wollen, wie Sie Unsicherheiten und schädliche Mehrdeutigkeiten in einem Projekt vermeiden oder sogar beseitigen können und wie Sie
User Story Akzeptanzkriterien klar formulieren können, lesen Sie diesen Artikel.
Viel Spaß beim Lesen!
Was ist eine User Story?
Eine sehr gute Definition einer User Story findet sich in dem Artikel "User Stories with examples and a template", der im Atlassian Blog veröffentlicht wurde.
Ihr Autor, Max Rehkopf, definiert User Storys als eine "informelle, allgemeine Erklärung von Softwarefunktionen, die aus der Perspektive des Endanwenders geschrieben wird".
Seiner Meinung nach dient eine User Story in erster Linie dazu, "festzustellen, wie eine bestimmte Softwarefunktion dem Kunden Nutzen bringt".
Die Beobachtungen im Artikel "What is User Story?" im Visual Paradigm Blog bieten eine hervorragende Ergänzung zur obigen Definition.
Die Autoren des Visual Paradigm weisen darauf hin, dass in der Softwareentwicklung und im Produktmanagement eine User Story ein Werkzeug ist, mit dem man die Bedeutung und das Wesen einer bestimmten Funktion aus der Sicht des Endbenutzers erfassen kann.
Mit der User Story können Sie Folgendes bestimmen:
- Was will der Nutzer?
- Warum wollen sie es?
Darüber hinaus bieten User Storys eine vereinfachte Beschreibung der Benutzeranforderungen.
Bei der Betrachtung von User Storys aus einer anderen Perspektive muss betont werden, dass User Storys nicht mit Anwendungsfällen verwechselt werden dürfen.
Obwohl es sowohl bei Anwendungsfällen als auch bei User Storys darum geht, Benutzeranforderungen zu definieren, zu bestimmen, zu extrahieren und zu kommunizieren, was die Benutzer mit dem System tun können, sind diese beiden Werkzeuge nicht gleichwertig.
User Storys werden von Anwendungsfällen abgeleitet. Mehr über die Gemeinsamkeiten und Unterschiede zwischen diesen Werkzeugen finden Sie im Artikel "User Story vs. Anwendungsfall".
Ohne ins Detail zu gehen, sei hier nur gesagt, dass User Storys weiter definierte Benutzeranforderungen für ein System, z.B. eine Webanwendung, sind.
Zum Beispiel, wenn ein Anwendungsfall ist:
"Online-Shop - Produkt zu den Favoriten hinzufügen".
Die User Story, die auf diesem Anwendungsfall basiert, lautet dann:
"Als Kunde eines Online-Shops möchte ich Produkte in eine Favoritenliste aufnehmen können, um in Zukunft leichter darauf zugreifen und sie schneller kaufen zu können."
Die allgemeine Matrix, die es Ihnen ermöglicht, User Storys zu definieren, hat die folgende Form:
"Als (bestimmter Nutzertyp) möchte ich (eine bestimmte Handlung ausführen), um (ein bestimmtes Ziel zu erreichen/ein bestimmtes Ergebnis zu erzielen/einen Wert zu realisieren)". Als detailliertere Variante eines Anwendungsfalls gibt eine User Story nicht nur das Ziel an, sondern definiert auch die Motivation, den Grund, den Nutzen, die Pläne und die Möglichkeiten, die dem Benutzer durch eine bestimmte Funktionalität geboten werden.
In der Praxis werden User Storys von verschiedenen Stakeholdern geschrieben, z. B. von Kunden oder Mitgliedern des Design- und Entwicklungsteams.
In der agilen Methodik ermöglicht Ihnen eine User Story:
- Entdecken Sie die Bedürfnisse der Endnutzer.
- Definieren Sie Anforderungen im Produkt-Backlog.
- Verstehen Sie die Absichten des Endnutzers.
- Bieten Sie relevante und gewünschte Funktionen an, die für den Endnutzer nutzbar sind.
Das Hauptziel, das mit einer User Story erreicht werden soll, ist die Definition der Rollen, die die Benutzer in einem bestimmten System spielen.
Mithilfe von User Storys können Sie auch wünschenswerte Aktionen aus der Sicht des Endbenutzers bestimmen.
Mit User Storys können Sie auch Ziele festlegen, bestimmen, was die Endbenutzer erreichen wollen, und klären, was eine bestimmte Aktion erfolgreich und zufriedenstellend macht.
Allgemeiner ausgedrückt, stellen User Storys in der agilen Methodik die grundlegende Methode zur Identifizierung der realen und nicht der postulierten oder imaginierten Bedürfnisse der Benutzer dar.
Wie schreibt man eine gute User Story?
Beim Schreiben einer User Story ist es gut, verschiedene Vorlagen und Techniken zu verwenden.
Zum Beispiel die beliebteste Methode, bei der eine User Story die drei wichtigsten Fragen beantwortet:
- Wer? — Wer interagiert mit dem System, und in welcher Rolle
- Was? — Was ein Benutzer von dem System erwartet
- Warum? — Warum interagiert ein Benutzer mit dem System, und welche Vorteile und Ergebnisse erwartet er?
Die erste Frage zum Thema dient auch dazu, die Rolle des Benutzers im System zu definieren.
Die zweite Frage bezieht sich auf das Systemverhalten, die Funktionsweise, die Benutzeraktionen und die Systemreaktionen.
Die dritte Frage ermöglicht es Ihnen, den tatsächlichen Nutzen und die Ergebnisse zu ermitteln, die in Bezug auf das System nicht funktional oder extern sind.
Wenn Sie User Storys schreiben, sollten Sie auch:
- Legen Sie genau fest, wann eine Geschichte fertig ist, wann eine bestimmte Aufgabe abgeschlossen ist und welche Kriterien erfüllt sein müssen.
- Setzen Sie Prioritäten und unterteilen Sie die Aufgaben in Haupt- und Nebenaufgaben.
- Benutzer-Personas verwenden: User Storys sollten die Unterschiede berücksichtigen, die sich aus verschiedenen Benutzergruppen und unterschiedlichen Personas ergeben.
- Schreiben Sie User Storys unter Berücksichtigung der Prozessphase, in der sich der Benutzer befindet, und der Prozessphase, der die Story entspricht.
- Überlegen Sie, wie komplex sie sind und ob sie in einem einzigen Sprint erledigt werden können.
Es ist auch wichtig zu bedenken, dass User Storys ihren Lebenszyklus haben. User Storys durchlaufen im Prozess der digitalen Produktentwicklung sechs Stadien oder Phasen.
Ein Lebenszyklus von User Storys umfasst die folgenden Zustände:
- Anhängig
- Zu tun
- Diskutieren
- Entwicklung
- Bestätigen
- Beendet.
In jedem dieser Zustände oder Phasen nimmt eine User Story eine etwas andere Form an und zeichnet sich durch einen anderen Grad an Spezifität und Detailgenauigkeit aus. Sie ist auch das Ergebnis des unterschiedlichen Bewusstseins der Teams.
Anhängige User Storys enthalten nur eine kurze, unspezifische Beschreibung der Bedürfnisse des Benutzers. Eine solche Story erfordert eine Diskussion und die Anerkennung ihrer Bedeutung, was möglich ist, wenn die Anforderungen an das System und seine grundlegende Logik im Voraus festgelegt sind.
Zu tun-User Storys sind die Storys, die einer ersten Überprüfung unterzogen wurden, und als Ergebnis einer ebenso vorläufigen Diskussion wurden potenziell wichtige Storylisten erstellt.
Die diskutierten User Storys sind die Storys, in denen die Anforderungen sehr viel detaillierter dargelegt werden.
Entwickelte User Storys sind die Storys, in denen die meisten Benutzererwartungen umgesetzt werden.
Bestätigte User Storys sind die Storys, die in der Testumgebung implementiert werden, um die Funktionen zu bestätigen.
Beendete User Storys sind Storys, die als abgeschlossen gelten.
Die Effektivität des Schreibens von User Storys hängt auch davon ab, ob das Team sie schreibt:
- Nimmt konsequent die Perspektive der Endnutzer ein. Wenn die Personen, die die User Storys schreiben, nicht wissen, wer die Nutzer sind und warum sie ein digitales Produkt nutzen, sollten sie die Storys nicht schreiben, denn das Ergebnis wird eher eine Vermutung, eine Hypothese oder eine Vorstellung sein als eine echte Widerspiegelung der Bedürfnisse, Ziele und Motivationen.
- Setzt Personas ein, um die Bedürfnisse und Erwartungen der Endnutzer besser zu verstehen.
- Schreibt konsequent einfache und prägnante, leicht verständliche und nachvollziehbare User Storys.
- Wird User Storys konsequent stratifizieren: wird allgemeine Storys (Epic Storys) und darauf aufbauend immer detailliertere Storys erstellen, die sich leichter in spezifische zeitbasierte Aufgaben umsetzen lassen.
- Wird einen klaren und spezifischen Satz von User Story Akzeptanzkriterien in den Prozess der Aufteilung von Epic Storys in User Storys einbeziehen.
- Sie sorgen für eine angemessene Sichtbarkeit, Verfügbarkeit und Verständlichkeit, sodass jedes Teammitglied leicht und fast direkt darauf zugreifen kann, um sich ein Gesamtbild zu verschaffen.
Was sind die Akzeptanzkriterien der User Story?
User Storys sind ein wichtiger Bestandteil der agilen Methodik. Sie definieren den Rahmen für die tägliche Arbeit der Entwicklerteams.
Um die Arbeit zu rationalisieren, müssen die Bedingungen, die erfüllt sein müssen, damit eine Story als vollständig gilt, eindeutig festgelegt werden.
Dies ist der Zweck der Definition von Akzeptanzkriterien.
Sie ermöglichen es Ihnen, die Vorstellungen der Stakeholder und des Entwicklerteams zu einer bestimmten Funktionalität oder einer bestimmten User Story abzustimmen und zu koordinieren.
Mit den dokumentierten Akzeptanzkriterien wissen die Entwickler, wie sich ein System oder eine bestimmte Funktionalität verhalten sollte, um seinen Betrieb aus der Perspektive der Erwartungen als korrekt zu betrachten.
Die User Story, Akzeptanzkriterien und Definition of Done sind Anforderungen, die erfüllt sein müssen, damit eine bestimmte Story als abgeschlossen gilt.
Die Anforderungen beziehen sich auf den Umfang, den Kontext und die Bedingungen, die von der Software — oder in der Regel von deren Teilen — erfüllt werden müssen, damit sie vom Benutzer und/oder den Stakeholdern akzeptiert wird.
Jedes Akzeptanzkriterium sollte unabhängig getestet werden und klare Szenarien für den Fall eines Erfolgs oder Misserfolgs enthalten.
Die Nützlichkeit der Akzeptanzkriterien einer User Story drückt sich in erster Linie in den Kriterien aus:
- Prüfbarkeit, die eindeutig bestimmen sollte, ob das erzielte Ergebnis eine Akzeptanz bedeutet oder nicht.
- Klarheit, fast eine Selbstverständlichkeit.
- Prägnanz.
- Einfachheit.
- Nachvollziehbarkeit.
- Konzentration auf den Nutzer, seine Perspektive, Bedürfnisse und Ziele.
- Realismus: Sie sollten die authentische Benutzererfahrung wiedergeben.
Die User Story Akzeptanzkriterien, die die oben genannten Eigenschaften in greifbarer Form besitzen, helfen den Entwicklerteams, das zu erstellende Produkt zu verstehen.
Ihr Vorteil liegt vor allem in der Verringerung von Unsicherheiten, Mehrdeutigkeiten, Fehlern, Missverständnissen und Unzulänglichkeiten.
Die effektiven Akzeptanzkriterien ermöglichen es Ihnen:
- Erzielen Sie eine größere Eindeutigkeit in Bezug auf die Erwartungen.
- Minimieren Sie das Risiko, dass die Erwartungen unterschiedlich verstanden werden.
- Extrahieren und Klären der Kunden- und Nutzervision.
- Kontrollieren Sie die Interpretationen und Diskrepanzen.
- Definieren Sie Grenzen.
- Entscheiden Sie, ob eine Anwendung wie erwartet funktioniert.
- Angleichung der Sichtweise des Kunden und des Entwicklerteams: Beide Parteien sind mit den Bedingungen und Erwartungen vertraut und wissen, wie sie den Betrieb einer bestimmten Anwendungsfunktion erstellen und bewerten können.
- Testen Sie den Betrieb des Systems.
- Aufgaben planen.
- Verhinderung von Unklarheiten über den Umfang, d. h. einer Situation, in der das Fehlen definierter Umfänge und Kriterien dazu führt, dass eine Geschichte anfällig für Änderungen ist, was sich auf den Zeitplan, das Budget, den reibungslosen Ablauf, die Arbeitsproduktivität und die Atmosphäre im Team auswirkt.
- Vermeiden Sie Fehler, Misserfolge und Missverständnisse.
- Verbesserung der Kommunikation: Das Team und die Beteiligten können viel weniger Zeit für das gegenseitige Verständnis aufwenden.
Die User Story Akzeptanzkriterien treten normalerweise in einer der beiden grundlegenden Varianten oder Formate auf:
- Regelorientierte Akzeptanzkriterien (Checklistenvorlage)
- Szenario-orientierte Akzeptanzkriterien (Vorlage "gegeben/ wenn/dann")
Die User Story Akzeptanzkriterien im szenarioorientierten Format haben die Form der folgenden Sequenz:
- Unter Berücksichtigung der Voraussetzungen.
- Wenn ich eine Aktion durchführe.
- Ich erwarte ein Ergebnis.
Aufgrund des Ursache-Wirkungs-Charakters ermöglicht diese Art von Szenario die Erfassung von Anforderungen, die Vorhersage verschiedener Anwendungsfälle und die Durchführung automatischer Akzeptanztests.
Der Vorteil dieses Szenarios ist der geringere Zeitaufwand für die Erstellung von Testfällen.
Wenn Sie einige Beispiele für Akzeptanzkriterien sehen möchten, empfehlen wir Ihnen den Artikel "Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices."
Für die Checklistenvorlage wird in der Regel die INVEST-Formel verwendet.
INVEST ist eine Checkliste (eine Liste, eine Reihe von Kriterien), die zur Bewertung der Qualität einer User Story verwendet wird, und sie hilft beim Schreiben guter Akzeptanzkriterien. Das Akronym stammt übrigens aus dem Englischen.
Nach dieser Formel sollte eine gute User Story sein:
- I (Independent) — Unabhängig von anderen User Stories.
- N (Negotiable) — Verhandlungsfähig: sie sollte ein Gespräch eröffnen, nicht abschließen; solange sie Teil des Backlogs ist, kann sie geändert und präzisiert werden.
- V (Valuable) — Wertvoll aus Sicht des Nutzers, es sollte dem Nutzer einen gewissen Nutzen bieten.
- E (Estimable) — Abschätzbar: Nur in einer solchen Formel kann sie in Aufgaben unterteilt und terminiert werden.
- S (Small) — Klein: Es sollte in kürzester Zeit umgesetzt werden können.
- T (Testable) – Prüfbar: Sie sollte zu einer endgültigen Entscheidung führen: Abgeschlossen / Nicht abgeschlossen.
Bei der Formulierung von Akzeptanzkriterien sollten Sie darauf achten, dass diese Kriterien erfüllt sind:
- Nachvollziehbar, realistisch und realisierbar.
- Von allen (Entwicklern und Stakeholdern) geteilt: Ergebnis eines Konsenses.
- Messbar: Ermöglicht es Ihnen, die Zeit abzuschätzen.
Zusammenfassend lässt sich sagen, dass gut formulierte Abnahmekriterien dem Team einen bestimmten Arbeitsumfang vor Beginn der Arbeit vorgeben. Das Team sollte wissen, was es baut.
Außerdem können Sie so eine gemeinsame Plattform für das Verständnis von Bedürfnissen, Zielen und Problemen schaffen. Ebenso wichtig ist die Möglichkeit, die Storys durch automatisierte Tests zu überprüfen.
Wer schreibt die Akzeptanzkriterien?
Bei der Erstellung der User Story Akzeptanzkriterien werden die besten Ergebnisse durch die Zusammenarbeit zwischen dem Kunden/Stakeholder und dem Entwicklerteam erzielt. Daher kann jeder aus dem funktionsübergreifenden Team Akzeptanzkriterien schreiben.
Der Prozess der Entwicklung von Akzeptanzkriterien sollte Teamarbeit aus der Geschäfts- und der reinen Designperspektive beinhalten.
Die Kriterien beschreiben den Bedarf des Nutzers. Daher sollten alle Akzeptanzkriterien auf Personas basieren und vor Beginn der Entwicklungsarbeit erstellt werden.
Mit diesem Ansatz können Sie definitiv viel schneller vorankommen:
- Erreichen Sie das Ziel.
- Konfrontieren Sie die Bedingungen der Möglichkeit (z. B. wenn es technische Einschränkungen gibt).
- Erzielen Sie einen Konsens, z. B. zwischen dem Standpunkt des Product Owners und dem der anderen Stakeholder.
- Richten Sie die Perspektiven aus.
- Planen Sie die Arbeit.
- Entwickeln Sie die Designdokumentation.
Der Auftragnehmer beauftragt in der Regel einen Bedarfsanalytiker und/oder einen Projektmanager mit der Erstellung der User Story Akzeptanzkriterien.
Aber denken Sie daran, dass es keinen Grund gibt, die anderen Teammitglieder, das gesamte Entwicklerteam, nicht in diese Arbeit einzubeziehen.
Dies gilt umso mehr, als der empfohlene Standard zur Erreichung des gewünschten Ergebnisses die Team- oder Gruppenarbeit ist.
Vor allem auf der Grundlage eines Dialogs, der es Ihnen ermöglicht, die Bedürfnisse besser zu ergründen, die Nuancen aufzugreifen und die Erwartungen weiter zu klären.
Was ist die Definition of Done (DOD)?
Die Frage, ob eine bestimmte Funktionalität abgeschlossen/erledigt ist, ist wahrscheinlich eine der schwierigsten Entscheidungen, die die Teams, die digitale Produkte mit agilen Methoden entwickeln, treffen müssen.
Die Definition of Done betrifft:
- Qualität digitaler Produkte
- Hervorragende Qualität des digitalen Produkts
- Seine Wettbewerbsfähigkeit
- Benutzerfreundlichkeit
- Einwandfreier Betrieb
- Benutzererfahrung.
Die Definition of Done wird in der Regel als eine Situation definiert, in der alle Bedingungen oder User Story Akzeptanzkriterien für ein digitales Produkt erfüllt sind. Eine bestimmte Funktionalität ist fertiggestellt, wenn sie die Akzeptanzkriterien erfüllt und bereit ist, von den Nutzern und Stakeholdern überprüft und akzeptiert zu werden.
Nach einer anderen Definition, die die obige ergänzt, ist die Defintion of Done eine Liste von Anforderungen, die eine User Story erfüllen muss, damit das Entwicklerteam und die Stakeholder sie als abgeschlossen betrachten.
Der Unterschied zwischen den Akzeptanzkriterien der User Story und der Defintion of Done besteht darin, dass sich die Akzeptanzkriterien der User Story auf jede einzelne Story beziehen, während die Definition of Done für alle User Storys gilt.
Um eine bestimmte User Story abzuschließen, müssen sowohl die in der Definition of Done festgelegten Kriterien als auch die Akzeptanzkriterien, der User Story erfüllt sein.
Genauer gesagt, kann eine User Story in der agilen Methodik als abgeschlossen betrachtet werden, wenn:
- Alle Zulassungskriterien sind erfüllt.
- Die Story wird vom Product Owner akzeptiert.
- Die User Story wird in der Produktionsumgebung implementiert.
- Die Story ist erfolgreich getestet worden.
- Die Funktionstests wurden erfolgreich bestanden.
- Die nicht-funktionalen Anforderungen sind erfüllt.
Die Antworten auf die folgenden Fragen sind hilfreich für die Entwicklung der Definition of Done:
- Wurde der Code vervollständigt?
- Ist der Code überprüft worden?
- Wurden die Einheitstests bestanden?
- Wurden die Funktionstests bestanden?
- Wurden die Abnahmeprüfungen abgeschlossen?
User Story. Scrum Akzeptanzkriterien. Zusammenfassung
- Die Prozessakzeptanzkriterien, Projektakzeptanzkriterien und User Story Akzeptanzkriterien sind nur scheinbar einfach zu definieren.
- User Stories sind informelle, allgemeine Erklärungen von Softwarefunktionen, die aus der Perspektive des Endbenutzers geschrieben werden.
- Eine User Story wird in erster Linie verwendet, um zu bestimmen, wie eine bestimmte Softwarefunktion dem Kunden Nutzen bringt.
- Die allgemeine Matrix, die es Ihnen ermöglicht, User Stories zu definieren, hat die folgende Form: Als (bestimmter Benutzertyp) möchte ich (eine bestimmte Aktion ausführen), um (ein bestimmtes Ziel zu erreichen / ein bestimmtes Ergebnis zu erhalten / einen Wert zu realisieren).
- Als detailliertere Variante eines Anwendungsfalls gibt eine User Story nicht nur das Ziel an, sondern definiert auch die Motivation, den Nutzen und die Möglichkeiten, die dem Benutzer durch eine bestimmte Funktionalität geboten werden.
- In der agilen Methodik sind User Stories die grundlegende Methode, um die tatsächlichen Bedürfnisse der Benutzer zu ermitteln.
- Detailliertere Kriterien sollten zum Verständnis des Ziels führen. Sie sollten es den Entwicklern ermöglichen, von Anfang an zu wissen, wie sich ein System oder eine bestimmte Funktionalität verhalten sollte, um seinen Betrieb aus der Perspektive der Erwartungen als korrekt zu betrachten.
- In Scrum, in IT-Projekten, sind die User Story Akzeptanzkriterien und Testakzeptanzkriterien eine Reihe von Anforderungen, die erfüllt werden müssen, um eine bestimmte Story als abgeschlossen zu betrachten.
- So können Sie Missverständnisse bereits in der Erstellungsphase vermeiden. Infolgedessen sind bei der Umsetzung einer Geschichte keine Korrekturen erforderlich, und das Endprodukt wird es dem Benutzer ermöglichen, seine primären Ziele zu erreichen.
- Bei der Erstellung der User Story Akzeptanzkriterien werden die besten Ergebnisse durch die Zusammenarbeit zwischen dem Kunden/Stakeholder und dem Entwicklerteam erzielt.
- Um eine bestimmte User Story abzuschließen, müssen sowohl die in der Definition of Done festgelegten Kriterien als auch die Akzeptanzkriterien, der User Story erfüllt sein.
