Schreiben einer guten User Story

Was ist eine User Story?

Eine User Story repräsentiert einen kleinen geschäftlichen Nutzen, den ein Team in einer Iteration bereitstellen kann. Während herkömmliche Anforderungen (z. B. Anwendungsfälle) so detailliert wie möglich sein sollten, wird eine User Story schrittweise in drei Phasen definiert:

  • Kurze Beschreibung des Bedarfs
  • Gespräche bei der Backlog-Pflege und Iterationsplanung zur Untermauerung der Details
  • Tests, die den zufriedenstellenden Abschluss der Story bestätigen

Wohlgeformte Storys erfüllen die Kriterien des INVEST-Akronyms von Bill Wake:

Unabhängig Wir möchten in jeder beliebigen Reihenfolge entwickeln können.
Verhandelbar Vermeiden Sie zu viele Details; halten Sie sie flexibel, sodass das Team anpassen kann, welche Teile der Story implementiert werden.
Nützlich Benutzer oder Kunden erhalten einen Nutzen durch die Story.
Schätzbar Das Team muss sie für die Planung verwenden können.
Klein Große Storys können schwieriger geschätzt und geplant werden. Zum Zeitpunkt der Iterationsplanung sollte die Story innerhalb der Iteration entwickelt, codiert und getestet werden können.
Testbar Dokumentieren Sie Akzeptanzkriterien oder die Definition of Done für die Story, die zu Testfällen führen.

Warum User Storys verwenden?

  • Geschäftlichen Nutzen formulieren
  • Vermeiden, Details zu früh einzuführen, die Designoptionen verhindern und Entwickler unangemessen auf eine Lösung festlegen
  • Darstellung nicht vorhandener Vollständigkeit und Übersichtlichkeit vermeiden
  • Ausreichend kleine Teile erhalten, die für Verhandlung und Bewegung im Backlog sorgen
  • Technische Funktionen Architekt, Entwicklern, Testern usw. überlassen

Wie schreibe ich User Storys?

Wenn Sie Storys erstellen, kann eine Vorlage sicherstellen, dass Sie nicht versehentlich technische Aufgaben erstellen:

Als benötige ich , um .

Beispiele:

  • Als Konsument benötige ich eine Warenkorbfunktionalität, um Artikel einfach online zu erwerben.
  • Als Manager benötige ich einen Bericht, um zu verstehen, welche Abteilungen ihre Produktivität verbessern müssen.

Versuchen Sie, die generische Rolle "Benutzer" zu vermeiden, wenn Sie User Storys schreiben. User Storys drehen sich um die Rolle, die mit dem System interagiert oder einen Wert oder Nutzen aus dem System zieht. Nicht alle Akteure sind Endbenutzer. Beispielsweise kann eine Rolle ein anderes System oder eine Person sein, die eine bestimmte Funktionalität benötigt, um Ihr Produkt zu kaufen, das Produkt aber tatsächlich nie verwendet. Es kann hilfreich sein, Aggregatrollen (wie Konsument) und spezielle Rollen (wie Suchender oder häufiger Einkäufer) zu erstellen.

In CA Agile Central sollte diese Vorlage oben im Feld "Beschreibung" eingegeben werden. Dies legt den Rahmen für die Details und Akzeptanzkriterien fest, die unten eingegeben werden.

Welche Größe sollte eine User Story haben?

Eine Story sollte klein genug sein, um in einer Iteration codiert und getestet zu werden – im Idealfall nur wenige Tage. Wenn eine Story zu groß ist, spricht man von einer Epic Story. Backlog-Elemente sind häufig zunächst Epic Storys, wenn sie eine niedrigere Priorität haben. Für die Release-Planung sollte Epic Storys in kleinere Teile zerlegt werden, aber nicht zu klein sein (keine Details).

Wie detailliert sollte eine User Story sein?

Zu umfassend
  • Ein Teammitglied kann den Iterationsstatus anzeigen.

Zu detailliert

  • Ein Teammitglied kann eine Tabelle mit Storys mit Rang, Name, Größe, Paket, Eigentümer und Status anzeigen.
  • Ein Teammitglied kann auf eine rote Schaltfläche klicken, damit die Tabelle Details zu allen Aufgaben mit Rang, Name, Schätzung, Eigentümer und Status anzeigt.

Genau richtig

  • Ein Teammitglied kann die Storys der Iteration und ihren Status mit den Hauptfeldern anzeigen.
  • Ein Teammitglied kann das aktuelle Burndown-Diagramm auf der Statusseite anzeigen und darauf klicken, um es zu vergrößern.
  • Ein Teammitglied kann die Aufgaben unter den Storys anzeigen oder ausblenden.
  • Ein Teammitglied kann eine Aufgabe auf der Iteration-Statusseite bearbeiten.

Wann füge ich Details hinzu?

Akzeptanzkriterien bieten die Definition of Done für die Story. Wenn Details zur Story vorhanden sind, erfassen Sie die kritischen Details als Akzeptanzkriterien. Der Product Owner sollte so viele Akzeptanzkriterien wie möglich auflisten, um die Absicht der Story zu verdeutlichen. Unabhängig davon, wie detailliert die Akzeptanzkriterien sind, sollte das Team über sie sprechen und sie anpassen, um die Ergebnisse der Diskussion zu erfassen. Sobald eine Iteration begonnen hat, können Tester Akzeptanzkriterien in Akzeptanztests formalisieren.

Platzieren Sie in CA Agile Central die Akzeptanzkriterien direkt unter der Nutzenaussage im Feld "Beschreibung". Mitgliedern des Bereitstellungsteams steht ein zentraler Bereich zur Verfügung, um alle Story-Informationen mit dieser Methode anzuzeigen. Mithilfe von Aufzählungszeichen können Sie jedes Kriterienelement kurz und klar halten.

Wer verwendet User Storys?

Erstellung: Kunde, Kunden-Proxy, Product Owner und andere Benutzer, die einen Bedarf für das Produkt identifizieren, können zu User Storys beitragen.
Eigentum und Wartung: Der Product Owner ist Eigentümer der User Storys und für das Erstellen, Erfassen, Verwalten und Priorisieren verantwortlich.
Verwendung: Entwickler, Tester und technische Redakteure verwenden User Storys, um zu wissen, was sie implementieren müssen und wann sie fertig sind. Product Owners verfolgen den Gesamtfortschritt basierend auf dem Status der User Storys nach. Das Management verfolgt User Storys üblicherweise zusammengefasst als Epic Storys oder Funktionen nach.

Was sind die häufigsten Fehler?

  • Zu formal oder zu viele Details. Product Owners mit guten Absichten versuchen häufig, extrem detaillierte User Storys zu schreiben.  Wenn ein Team eine Story bei der Iterationsplanung sieht, die wie ein Dokument mit IEEE-Anforderungen aussieht, wird häufig angenommen, dass alle Details vorhanden sind. Ein ausführliches Gespräch findet nicht statt.
  • Technische Aufgaben, die als Storys getarnt sind. Ein Großteil der Vorteile von Agile rührt daher, dass am Ende jeder Iteration ein funktionierendes Softwareinkrement vorhanden ist.  Wenn Ihre Storys eigentlich nur technische Aufgaben sind, steht Ihnen am Ende jeder Iteration oft keine funktionierende Software zur Verfügung, und Sie verlieren die Flexibilität bei der Priorisierung.
  • Es findet kein Gespräch statt. Storys sind vor der Iterationsplanung absichtlich vage.  Wenn kein Gespräch zu Akzeptanzkriterien stattfindet, riskieren Sie Folgendes: Sie bewegen sich in die falsche Richtung, verpassen Grenzfälle oder übersehen Kundenanforderungen.

Beispiel

Es folgt eine Beispiel-User Story in CA Agile Central. Diese Story wurde vom Team in mehreren Pflege- und Planungsmeetings besprochen, während sie das Backlog durchlief, und wird bald für eine kommende Iteration geplant. Der Zweck dieser User Story ist es, Käufern auf einer Website die Zahlung per Kreditkarte zu ermöglichen.

Feedback

Benötigen Sie weitere Informationen? Die CA Agile Central-Community ist Ihre zentrale Anlaufstelle für Self-Service und Support. Treten Sie der CA Agile Central-Community bei, um dem CA Agile Central-Support Feedback mitzuteilen oder Fälle zu melden, Antworten zu finden oder mit anderen Benutzern zusammenzuarbeiten.