Sollte eine User Journey Teil einer BDD-Story sein?

Ich schreibe eine Vorlage für ein Story-Dokument und möchte so viele Elemente enthalten, wie für nützliche, generische Storys erforderlich sind. Derzeit umfasst dies:

  • Geschichte Nummer
  • Punkteschätzung (fibonacci)
  • Status (to do, in dev, done usw.)
  • Priorität
  • Gesperrte Flagge
  • Autor
  • Bevollmächtigter
  • Titel
  • Kurze Beschreibung
  • Beschreibung
  • Technische Hinweise (Aufzählungspunkte nur als Referenz)
  • Akzeptanzkriterien (Aufzählungspunkte, die vor dem Testen angekreuzt werden müssen)
  • Szenarien (angegeben Wenn Dann für jeden einzigartigen Anwendungsfall)
  • User Journeys (Optionale Variationen als nummerierte Schritte, die auf die Szenarien angewendet werden können, um Variationen von Tests bereitzustellen)

Meine Frage ist: Sollte ich User Journeys ganz vermeiden oder haben sie noch einen Platz in dieser Art von Geschichte?

Übersehe ich auch irgendetwas, das Sie als Entwickler oder Story-Autor anspringen könnte?

Antworten (2)

Es hängt von der Geschichte und dem Team ab. Während der Sprint-Planung würden Sie also die hochwertigen Geschichten mit dem Entwicklungsteam besprechen, das im Gegenzug um Klarheit bittet. Sie sollten sie fragen, ob das Hinzufügen einer User Journey hilfreich ist.

Eine Randbemerkung hier: Glauben Sie, dass Sie solche Details für jede einzelne Geschichte hinzufügen können, solange das Projekt läuft? Noch wichtiger, gibt es einen Grund, warum Sie all das dokumentieren müssen , anstatt nur mit dem Rest des Teams zu interagieren ?

Meine Vorliebe zum Backlog Refinement: Was das Product Backlog Management angeht, schreibe ich immer gerne so wenig wie möglich und zerlege die Stories so spät wie möglich, aber vor dem Sprint Planning. Während der Sprint-Planung zerlegen Sie dann weiter und fügen jeder Story zusammen mit dem Entwicklerteam Unteraufgaben hinzu, um das Sprint-Backlog zu erstellen. Offensichtlich können Sie das nicht für alle Geschichten tun, also respektieren Sie die Timebox und erledigen Sie den Rest, während der Sprint fortschreitet. Dies minimiert Verschwendung und ermöglicht es dem Team, sich auf den Wert zu konzentrieren.

Danke dir. Das wäre auch meine bisherige Erfahrung. Ich würde gerne wissen, ob Sie versuchen würden, Benutzerreisen neben Szenarien zu vermeiden, und wenn nicht, wie sie zusammenarbeiten können. Ich denke derzeit darüber nach, die Szenarien zu haben und Benutzerreisen zu verwenden, um unterschiedliche Daten für die Szenarien bereitzustellen, die als Testsuiten mit mehreren Eingaben implementiert werden sollen.
Eine Persona kann eine oder mehrere Reisen haben, wobei jede Reise ein oder mehrere Szenarien hat. Eine Reise umfasst in der Regel sogar Dinge, die außerhalb des Produkts passieren. Daher würde ich nicht vermeiden, sie zusammen zu verwenden.

Denken Sie daran, dass das agile Manifest den Wert von betont

Individuen und Interaktionen über Prozesse und Tools

Es sieht so aus, als ob Sie versuchen, User Stories zu einem zentralen Bestandteil des Prozesses zu machen. Sie sind Platzhalter für zukünftige Konversationen und das war's.

Beispielsweise führen Sie „Titel“, „Kurzbeschreibung“, „Beschreibung“ und „Szenarien“ ein. Warum braucht man das alles in einer User Story ?


Sollte ich User Journeys ganz vermeiden oder haben sie noch einen Platz in dieser Art von Geschichte?

User Journeys sollten Sie natürlich nicht vermeiden, sie sind Teil der Realität. Aber müssen Sie sie (und Szenarien) wirklich in die User Story einfügen? Werden sie nicht bereits von Ihren Tests abgedeckt, da Sie BDD machen? Sind sie hinterher nicht in Ihrer Dokumentation?

Szenarien (angegeben Wenn Dann für jeden einzigartigen Anwendungsfall)

"Given When Then" ist ein Format für Akzeptanztests, nennen Sie es besser so, um Verwechslungen mit Anwendungsfällen zu vermeiden. Abgesehen davon, wenn Sie "Given When Then" für Anwendungsfälle schreiben , sollten sie mit Anwendungsfällen verbunden sein, nicht mit Geschichten.