Effektive Storys in Agile Development 2.0 schreiben

Gut geschriebene Storys sind für alle Entwickler und andere Teammitglieder leicht verständlich, z. B. beim Testen oder für die Dokumentation.

Storys ermöglichen es der Zuweisungsgruppe, den für die Implementierung der Arbeit erforderlichen Aufwand im Hinblick auf die Definition von „Bereit“ genau abzuschätzen. Die Definition von „Bereit“ ist das von der Gruppe vereinbarte Beendigungskriterium, das bestimmt, wann eine Story abgeschlossen ist.

Eine Story hat die folgenden Grundbedingungen:

• Beschreibung: Die Story-Beschreibung bezieht sich auf eine Benutzerpersona, z. B. Administrator, und beschreibt entweder einen Geschäftsnutzen oder bezieht sich auf technische Schulden.
• Akzeptanzkriterien: Die Akzeptanzkriterien der Story sind messbar und testbar.

Story-Beschreibungen

Um die genannte Anforderung zu erfüllen, identifiziert eine gute Beschreibung einer User Story Folgendes:

• Rolle der Benutzerpersona im System
• Von Benutzerpersona geäußerter Bedarf
• Nutzen für alle Stakeholder wie Entwickler, Benutzer usw.

Normalerweise wird eine Story-Beschreibung wie folgt ausgedrückt: „Als<role> , möchte ich<goal or need> , damit<benefit> ".

Beispiele für eine gute Story-Beschreibung

• Beschreibung: Als Entwickler möchte ich den aktuellen Status meiner Anwendung in einem Update Set veröffentlichen, damit ich sie in einem Produktionssystem bereitstellen kann.
• Beschreibung: Als Kunde möchte ich Benachrichtigungen erhalten, wenn Kommentare zu einem Incident eingegeben werden, damit ich über den Status informiert werde.
• Beschreibung: Als Change-Manager möchte ich die Risikobewertung für einen bestimmten Change ermöglichen, indem ich eine Liste von Fragen mit Multiple-Choice-Antworten aufstelle.

Beispiele für eine schlechte Story-Beschreibung

Beschreibung: Benachrichtigungen werden gesendet, wenn Incidents erstellt werden.

Diese Beschreibung ist schlecht, weil:

• Die Beschreibung gibt nicht an, wer oder was Benachrichtigungen sendet oder in welcher Form die Benachrichtigung eingeht, z. B. per E-Mail.
• Die Beschreibung enthält keine Informationen zu einem Vorteil, sodass der Geschäftsnutzen nicht eindeutig ist.

Sie könnte besser geschrieben werden als:

Beschreibung: Als Ersteller von Incidents möchte ich, dass E-Mail-Benachrichtigungen an eine vordefinierte Gruppe von Interessenten gesendet werden, wenn ich einen Incident erstelle, damit sie informiert werden können, wenn ein Incident erstellt wird, der sie betrifft.

Story-Akzeptanzkriterien

Akzeptanzkriterien definieren die Grenzen einer User Story und werden verwendet, um zu bestätigen, dass die Software wie beabsichtigt funktioniert, was bedeutet, dass die Story abgeschlossen ist. Akzeptanzkriterien sind ein wesentlicher Teil der „Definition von Bereit“ für eine Story.

Gute Akzeptanzkriterien

Gute Akzeptanzkriterien sollten gegebenenfalls Folgendes umfassen:

• Verwendbarkeit: Stellen Sie sicher, dass die Akzeptanzkriterien Metriken für die Verwendung enthalten. Geben Sie an, wie die folgende Frage beantwortet werden soll: Ist es einfach zu verwenden? Der Schlüssel ist, die richtigen Messungen zu identifizieren und sicherzustellen, dass jede quantifizierbar ist.
• Funktionalität: Identifizieren Sie bestimmte Benutzeraufgaben, Geschäftsprozesse oder Funktionen, die am Ende des Projekts vorhanden sein müssen. Eine funktionale Anforderung kann sein: Der Benutzer kann aus mehreren Größen auswählen.
• Fehlerbehandlung: Listet Fehlerfälle auf und wie sie behandelt werden sollen. Beispiel: Wie reagiert die Software, wenn ein Benutzer die Schritte in der falschen Reihenfolge ausführt?
• Leistung: Testen Sie die Systemleistung aus der Perspektive eines einzelnen Benutzers. Beispiel: Reagiert die UI?
• Stresstests: Beschreiben Sie, wie das System reagiert, wenn es unter Stress steht, da viele Benutzer, Transaktionen oder Abfragen vorhanden sind. Akzeptanzkriterien sollten akzeptable Schwellenwerte für Stresstests definieren. Beispiel: Reagiert das System innerhalb eines Schwellenwerts von 250 Millisekunden, wenn 100 Benutzer gleichzeitig Abfragen senden?

Beispiel für gute Akzeptanzkriterien

Beschreibung: Als Kunde möchte ich das Buch über ein sicheres webbasiertes Formular bestellen und bezahlen, damit meine Kreditkarteninformationen sicher sind.

Akzeptanzkriterien:

• Alle Pflichtfelder müssen ausgefüllt werden, bevor ein Kunde ein Formular absenden kann.
• Informationen aus dem Formular werden in der Kundenauftragsdatenbank gespeichert.
• Die Zahlung kann über Amex-, Master Card- oder Visa-Kreditkarte erfolgen.
• Das System muss die Umsatzsteuer genau berechnen und anwenden.
• Das System muss die Versandkosten genau berechnen und anwenden.
• Der Kunde muss die Richtigkeit der Bestellung überprüfen können.
• Eine Bestätigungs-E-Mail wird an den Kunden gesendet, der das Formular absendet.
• Der Schutz vor Spam funktioniert.

Beispiel für schlechte Akzeptanzkriterien

Beschreibung: Als Kunde möchte ich Benachrichtigungen erhalten, wenn Kommentare zu einem Incident eingegeben werden, damit ich über den Status informiert werde.

Akzeptanzkriterien: Die entsprechenden Personen werden benachrichtigt, wenn Incidents kommentiert werden.

Die Akzeptanzkriterien sind schlecht, da sie nicht genügend Details zum Testen liefern, z. B. ist nicht klar, wer die entsprechenden Personen sind.

Die Akzeptanzkriterien könnten besser geschrieben werden als:

1. Erstellen Sie als ESS-Benutzer einen Incident.
2. Wählen Sie Interessierte Parteien benachrichtigen aus.
3. Speichern Sie den Incident.
4. Melden Sie sich als interessierte Partei an.
5. Überprüfen Sie, ob Sie eine E-Mail für den protokollierten Incident erhalten haben.