Benutzerstories beschreiben, wie eine neue Produktfunktionalität im Alltag oder in der Geschäftssprache funktioniert. Ihre Vorbereitung erfordert jedoch viel Zeit, Mühe und Überlegung. In diesem Beitrag weisen wir auf die häufigsten Fehler bei Benutzerstories hin und schlagen vor, wie man damit umgehen kann.

Die häufigsten Fehler bei Benutzerstories – Inhaltsverzeichnis:

  1. Einführung
  2. Probleme mit 3W
  3. Probleme mit 3C
  4. Fehler bei Benutzerstories – Zusammenfassung

Einführung

Benutzerstories können ein großartiges Werkzeug sein, um das Team zu motivieren, neue Lösungen für Probleme aus der Perspektive des Benutzers vorzuschlagen. Wir haben in einem separaten Beitrag darüber geschrieben, was eine Benutzerstory ist. Und in diesem Artikel haben wir INVEST vorgestellt, eine beliebte Methode zum Schreiben guter Benutzerstories. Heute werden wir uns auf Fehler bei Benutzerstories. konzentrieren.

Probleme mit 3W

Eine ordnungsgemäße Benutzerstory beantwortet die Fragen:

  • Wer? (Wer ist der Zielbenutzer des Produkts?)
  • Was? (Welche Fähigkeiten hat das Produkt und was kann es tun?)
  • Warum? (Welchen Zweck erfüllt es?)

Allerdings können Probleme mit den Antworten auf jede dieser Fragen einhergehen. Das am wenigsten verbreitete Problem ist der Zweifel daran, was sich im Produkt als Reaktion auf die Bedürfnisse des Kunden ändern sollte. Daher werden wir uns auf Probleme bezüglich Wer? und Warum? konzentrieren.

Fehler bei Benutzerstories

Wer – Benutzerpersona

Ein häufiger Fehler bei der Erstellung von Benutzerstories besteht darin, die Frage nicht präzise genug zu beantworten: für wen? Mit anderen Worten, wer ist der Benutzer, für den die geplante Änderung gedacht ist?

Oft reicht eine allgemeine Antwort, die auf den Kunden oder Endbenutzer als Empfänger der Änderung hinweist, nicht aus. Die Lösung für dieses Problem besteht darin, sich den Empfänger als spezifische Persona vorzustellen. Eine Persona ist ein Modellbild des Zielkunden. Mit anderen Worten, eine Persona ist eine Darstellung der Person, die das Produkt auf eine bestimmte Weise nutzen wird.

Nach der Analyse Ihrer Benutzerstory stellen Sie möglicherweise fest, dass sie die Geschichten verschiedener Personen gleichzeitig erzählt. Wenn es viele Zielbenutzer gibt, ist es sinnvoll, die Benutzerstory in kleinere Fragmente zu unterteilen, um widersprüchliche, sich gegenseitig ausschließende oder einfach ineffektive Maßnahmen zu vermeiden.

Warum? – ein schlecht definiertes Ziel

Manchmal wird der letzte Abschnitt der Benutzerstory zur Quelle von Problemen. Er sollte den geschäftlichen Wert der Änderungen spezifizieren, die während der Ausführung der Benutzerstory vorgenommen werden. Schauen Sie sich ein Beispiel für Fehler bei Benutzerstories an, bei dem die Beschreibung zusätzlicher Funktionalität das Ziel ersetzt:

Als Kunde möchte ich mit einem Klick einen Zauberstab kaufen, weil ich nächste Woche einen fliegenden Teppich kaufen möchte.

Anstatt den Grund für den Kauf des Zauberstabs anzugeben, fügt diese Benutzerstory einen weiteren Punkt zur Einkaufsliste des potenziellen Kunden hinzu. Daher sollten Sie bei der Vorbereitung einer Benutzerstory nicht die Gründe für Änderungen in der Funktionalität des Produkts. vergessen.

Probleme mit 3C

Wir können den Prozess der Arbeit mit Benutzerstories in drei Phasen unterteilen, die als 3Cs bezeichnet werden:

  • Karte – Die Karte, auf der die Benutzerstory gespeichert ist
  • Gespräch – Ein Gespräch innerhalb des Scrum-Teams über die Benutzerstory-Karte
  • Bestätigung – Definition von Akzeptanzkriterien, die bestätigen, dass eine Aufgabe abgeschlossen wurde

Fehler können in jeder dieser Phasen auftreten, die wir im Folgenden beschreiben.

Karte

Die Speicherkarte, die die Benutzerstory speichert, hat eine begrenzte Kapazität. Daher betreffen die häufigsten Probleme die Länge und den Umfang der Benutzerstory. Die Benutzerstory benötigt Kohärenz und kein Herumreden, wie man so schön sagt, in einem so präzisen Maße, dass jedes Wort zählt.

Das liegt daran, dass das Problem der Benutzerstory-Karte zwei Dimensionen hat. Eine ist die Art und Weise, wie sie formuliert ist: prägnant und mit einer notwendigen Mindestanzahl an Aufzählungen. Die zweite ist die tatsächliche Größe der Benutzerstory. Ein allgemeiner Satz kann eine riesige Anzahl von Aufgaben ausdrücken, die nicht während eines einzigen Sprints abgeschlossen werden können.

Gespräch

Die Formulierung der Benutzerstory in einem Satz ist der Ausgangspunkt für ein Gespräch mit dem Entwicklungsteam. Daher ist es falsch, sie als Beschreibung der auszuführenden Aufgabe zu behandeln. Dies schränkt die Möglichkeit von Verhandlungen und Diskussionen über verschiedene Umsetzungswege ein. Eine Benutzerstory sollte nicht als Beschreibung der Anforderungen an neue Produktfunktionalität betrachtet werden, sondern vielmehr als Einladung, ein Gespräch über spezifische technische Lösungen zu beginnen, die zur Verwirklichung des durch die Benutzerstory definierten Geschäftswerts führen.

Bestätigung

Wir haben ausführlich über die Akzeptanzkriterien geschrieben, die für jede Benutzerstory definiert werden müssen, im Text, der beschreibt, was eine Benutzerstory ist. Einer der häufigsten Fehler ist jedoch das Fehlen von Eindeutigkeit der Leistungskriterien.

Eine gut geschriebene Benutzerstory enthält eine Beschreibung der Situation, in der sie umgesetzt wird. Ihr Test ist, dass der Benutzer die neue Funktionalität, die vom Entwicklungsteam geschaffen wurde, nutzt.

Ein nützliches Werkzeug zur Validierung der Benutzerstory ist, einen Akzeptanztest zu entwickeln. Dies befindet sich normalerweise auf der Rückseite der Karte, die die Benutzerstory enthält.

Fehler bei Benutzerstories

Fehler bei Benutzerstories – Zusammenfassung

Bei der Vorbereitung und Anwendung von Benutzerstories ist es sinnvoll, sich an die folgenden Regeln zu halten:

  • Den Benutzer, der von der Änderung betroffen ist, präzise identifizieren
  • Den Zweck des Aufbaus neuer Produktfunktionalität klar definieren
  • Seinen Umfang so kurz wie möglich halten
  • Die Benutzerstory als Ausgangspunkt für Diskussionen mit dem Entwicklungsteam betrachten
  • Klare Regeln für die Akzeptanz festlegen

Wenn Ihnen unsere Inhalte gefallen, treten Sie unserer aktiven Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

Als Projektmanagerin ist Caroline eine Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

View all posts →