Was ist der Unterschied zwischen User Story und Akzeptanzkriterien?

Table of Contents hide

3.1 Beispielsweise müssen Teams in der Softwarebranche möglicherweise einige der folgenden Fragen stellen, um ihre DoD zu ermitteln:

4 Akzeptanzkriterium

5 Die Ziele der Akzeptanzkriterien

6 Beispiel – Akzeptanzkriterien

7 Beispiel einer User Story mit Akzeptanzkriterien

Definition of Done (DoD) ist eine Liste von Anforderungen, die eine User Story erfüllen muss, damit das Team sie als abgeschlossen bezeichnen kann. Während die Akzeptanzkriterien einer User Story aus einer Reihe von Testszenarien bestehen, die erfüllt werden müssen, um zu bestätigen, dass die Software wie erwartet funktioniert.

Der Unterschied zwischen diesen beiden besteht darin, dass die DoD für alle User Storys gleich ist, während die Akzeptanzkriterien für bestimmte User Storys gelten . Die Akzeptanzkriterien für jede User Story unterscheiden sich je nach den Anforderungen dieser User Story.

Mit anderen Worten, sowohl DoD- als auch Akzeptanzkriterien müssen erfüllt werden, um die User Story abzuschließen. Das Produktinkrement gilt nicht als vollständig, es sei denn, diese beiden Listen sind fertig. Daher müssen wir zwei Aspekte der Definition of Done (DOD) definieren – Abschlusskriterien und Abnahmekriterien:

Definition von Done

Die Definition von Done ist als Liste von Elementen strukturiert, die jeweils zur Validierung einer Story oder PBI verwendet werden, um sicherzustellen, dass sich das Entwicklungsteam über die Qualität der Arbeit einig ist, die es zu produzieren versucht. Es dient als Checkliste, mit der jedes Product Backlog Item (aka PBI) oder jede User Story auf Vollständigkeit geprüft wird. Elemente in der Definition von „Fertig“ sollen auf alle Elemente im Product Backlog anwendbar sein, nicht nur auf eine einzelne User Story . Es lässt sich wie folgt zusammenfassen:

Der Begriff bezieht sich eher auf das Produktinkrement als Ganzes
In den meisten Fällen impliziert der Begriff, dass das Produktinkrement lieferbar ist
Der Begriff ist im Scrum Guide definiert
Wird verwendet, um zwischen den Teammitgliedern zu kommunizieren
Allgemeine Softwarequalität
Ob das Inkrement lieferbar ist oder nicht

Die Ziele der Definition of Done

Schaffen Sie im Team ein gemeinsames Verständnis von Qualität und Vollständigkeit
Als Checkliste verwenden, mit der User Storys (oder PBIs) abgeglichen werden
Stellen Sie sicher, dass das am Ende des Sprints versendete Inkrement von hoher Qualität ist und dass die Qualität von allen Beteiligten gut verstanden wird.

Beispiel – Definition of Done

Beispielsweise müssen Teams in der Softwarebranche möglicherweise einige der folgenden Fragen stellen, um ihre DoD zu ermitteln:

Code-Peer-Review?
Code abgeschlossen?
Code überprüft?
Code eingecheckt?
Unit-Tests bestanden?
Funktionstests bestanden?
Abnahmetests abgeschlossen?
Product Owner überprüft und akzeptiert?

Akzeptanzkriterium

User Stories sind eines der primären Entwicklungsartefakte für die agile Entwicklung , aber Scrum verlangt nicht ausdrücklich, dass User Stories oder Akzeptanzkriterien verwendet werden. Wenn ein Produkt-Backlog-Element als zu groß für einen Sprint angesehen wird, wird es normalerweise in eine User Story und anschließend in eine Reihe von Aufgaben unterteilt, wie in der Abbildung gezeigt:

User Stories kapseln Akzeptanzkriterien, daher sehen wir in unserem Scrum-Entwicklungsprozess oft, dass die Definition of Done und die Akzeptanzkriterien nebeneinander bestehen. Die User Story stellt den Kontext der Funktionalität bereit, die das Team bereitstellen sollte. Die Akzeptanzkriterien geben Hinweise zu den Einzelheiten dieser Funktionalität und wie der Kunde sie akzeptieren wird. Die beiden zusammen liefern das gesamte Ergebnis.

Einige der Akzeptanzkriterien werden in Ongoing Backlog Refinement-Events vor Beginn des Sprints entdeckt, und andere werden direkt nach der Sprint-Planung entdeckt , wenn Sie sich zusammensetzen, um in einem kleinen Team ein Gespräch über die User Story zu führen. Akzeptanzkriterien sind also Attribute, die für die User Story oder das Product Backlog Item einzigartig sind.

Der Begriff gilt für eine einzelne PBI/Story
Die Akzeptanzkriterien sind für jede PBI/Story unterschiedlich
Begriff ist im Scrum Guide nicht definiert
Wird verwendet, um allen Beteiligten mitzuteilen, dass die Anforderungen für eine bestimmte PBI/Story erfüllt wurden
Auch Akzeptanztests, Zufriedenheitsbedingungen, in einigen Fällen „Testfälle“ usw

Die Ziele der Akzeptanzkriterien

Klären Sie, was das Team aufbauen soll, bevor es mit der Arbeit beginnt
Stellen Sie sicher, dass alle ein gemeinsames Verständnis des Problems haben
Helfen Sie den Teammitgliedern zu wissen, wann die Story abgeschlossen ist
Helfen Sie mit, die Story durch automatisierte Tests zu verifizieren.

Beispiel – Akzeptanzkriterien

Ein Benutzer kann kein Formular absenden, ohne alle Pflichtfelder ausgefüllt zu haben
Informationen aus dem Formular werden in der Registrierungsdatenbank gespeichert
Die Zahlung kann per Kreditkarte erfolgen
Nach dem Absenden des Formulars wird eine Bestätigungs-E-Mail an den Benutzer gesendet

Beispiel einer User Story mit Akzeptanzkriterien

Die folgende Abbildung zeigt ein Beispiel für Akzeptanzkriterien einer User Story.

Verweise