Das Format der User Stories ist klar definiert. Es handelt sich um Textdateien mit der Dateiendung .story. Die Beschreibung der User Story erfolgt nach einer festen Struktur. Nachfolgend ist eine User Story beispielhaft dargestellt.

@UserStory("1")
@UserStoryName("Name")
@Sprint("3")
@Priority("2")

DESCRIPTION:
Beschreibung der User Story.

REASON:
Grund für die User Story.

ACCEPTANCE-CRITERION 1:
Beschreibung der Anforderungen, die erfüllt sein müssen.

@AcceptanceTest("1.1")
GIVEN: Voraussetzung.
WHEN:  Durchführung.
THEN:  Überprüfung.

ACCEPTANCE-CRITERION 2:
Beschreibung der Anforderungen, die erfüllt sein müssen.

@AcceptanceTest("1.2")
GIVEN: Voraussetzung.
WHEN:  Durchführung.
THEN:  Überprüfung.

Jede User Story beginnt mit den vier Pflichtparametern:

@UserStory("...")

@UserStoryName("...")

@Sprint("...")

@Priority("...")

Mit @UserStory wird der User Story eine ID gegeben. In der Regel werden die User Stories mit fortlaufenden Nummern versehen. Unterschiedliche story-Dateien mit derselben ID werden als eine User Story betrachtet. Als @UserStoryName kann eine beliebige Zeichenkette angegeben werden. Der UserStoryName dient dem Anwender zur leichteren Unterscheidung der einzelnen User Stories. Mit @Sprint findet eine Zuordnung der User Story zu einem Sprint statt, in der die User Story umgesetzt werden soll. Der Entwicklungsprozess einer Software beginnt mit dem ersten Sprint, wobei die nachfolgenden Sprints in aufsteigender Reihenfolge nummeriert werden. Über @Priority wird für die User Story eine Priorität festgelegt. Die Priorität wird in der Regel durch den Product Owner vergeben. Innerhalb eines Sprints werden die User Stories gemäß ihrer Priorität umgesetzt.

Anschließend folgen mit DESCRIPTION und REASON zwei optionale Abschnitte, in denen die User Story beschrieben und der Grund für die User Story angegeben werden kann.

Nachfolgend sind eine Menge von Akzeptanzkriterien (ACCEPTANCE-CRITERION) aufgelistet, die alle erfüllt sein müssen, damit die User Story abgeschlossen ist. Jedes Akzeptanzkriterium kann wiederum aus einer beliebigen Anzahl von Akzeptanztests bestehen. Ein Akzeptanztest wird stets durch @AcceptanceTest("...") eingeleitet. Innerhalb der runden Klammern muss ein Schlüsselwert angegeben werden. Anhand der Schlüsselwerte findet eine Zuordnung von Akzeptanztests der User Story zu Methoden von Testklassen statt. Dabei werden nur die Methoden einer Klasse berücksichtigt, die mit der Annotation @AcceptanceTest("...") versehen sind. Die Annotation @AcceptanceTest ist Bestandteil der checkerberry-atdd-common.jar und über den vollqualifizierten Klassennamen de.conceptpeople.checkerberry.atdd.common.annotations.AcceptanceTest zu erreichen. In Maven-Projekten wird die checkerberry-atdd-common.jar wie folgt eingebunden.

<dependency>
  <groupId>de.conceptpeople.checkerberry</groupId>
  <artifactId>checkerberry-atdd-common</artifactId>
  <version>3.2.x</version>
</dependency>

Das folgende Beispiel zeigt eine annotierte Testmethode, die eine Zuordnung zum ersten Akzeptanzkriterium der oben dargestellten User Story herstellt.

@AcceptanceTest("1.1")
public void testMeTest(){
  ...
}

Wie das nachfolgende Beispiel zeigt, können über die Annotation @AcceptanceTest mehrere Schlüsselwerte angegeben werden. Dies ist erforderlich, wenn eine Testmethode mehrere Akzeptanzkriterien validiert.

@AcceptanceTest({"1.1", "1.2", "2.4"})
public void testVariousTest(){
  ...
}

Ein Akzeptanztest kann durch die Angabe von GIVEN, WHEN und THEN näher beschrieben werden. GIVEN beschreibt die Voraussetzungen, welche vor der Durchführung des Tests vorhanden sind. WHEN beschreibt, welche Aktionen durchgeführt werden. THEN gibt an, welche Zustände nach der Durchführung geprüft bzw. vorhanden sein müssen.

Hinweis: Da das @-Zeichen stets ein Schlüsselwort markiert, darf das Zeichen nur an den vorgesehenen Stellen verwendet werden. Für den Fall, in dem das Zeichen kein Schlüsselwort einleiten soll, ist stattdessen der enkodierte Wert für das @-Zeichen zu verwenden. Der enkodierte Wert ist @.