User Story in Scrum definieren: Wie spezifisch müssen sie sein? [Duplikat]

Wie der Titel schon sagt: zum Beispiel die folgende User Story zu allgemein?

"A registered user wants to login in order to use the site's services"

Oder sollte ich detailliertere User Stories verwenden, wie die folgenden?

1. "User insert email and password in the textboxes and click the login button";

2. "Server receives login data and check if they contain errors";

3. "Server puts the new user in the database if the login data are correct";

4. "The logged user is brought to his profile page".

Es scheint, je spezifischer es ist, desto besser verstehen wir den erforderlichen Teil der Codes (1) "Textfelder", 1) "Anmeldeschaltfläche", 3) "Datenbank", ...).

Welches ist der richtige Weg zwischen diesen beiden?

Auch wenn Ihre Frage kein genaues Duplikat ist, verbessern Sie bitte Ihre Frage, indem Sie erklären, warum Antworten wie diese (und zahlreiche andere verwandte Fragen und Antworten) Ihr Problem nicht angemessen ansprechen.

Antworten (3)

User Stories sollten genügend grundlegende Informationen enthalten, z. B. wer (Benutzertyp) welche Funktionalität wünscht und warum die Funktionalität benötigt wird. Auch, was sein oder ihr Erfolgskriterium für die Geschichte ist. Details sollten in der User Story vermieden werden, da sie im Rahmen des Sprint-Planungsmeetings besprochen werden. Es ist sehr schwierig, die richtige Balance zu finden, aber ein erfahrener Scrum Master kann die produktive Diskussion wirklich erleichtern. Als Faustregel gilt, dass sie spezifisch genug sein sollte, damit die Story eine gute Chance hat, in einem Gedränge fertig zu werden.

Das oben genannte Beispiel scheint jedoch einige Aufgaben zu haben, die von den Teammitgliedern definiert und entschieden werden. User Stories sollten in der Regel von Product Ownern (PO) stammen

Ich stimme hier zu. Die Beispiele in der Frage sind keine guten Geschichten. „Benutzer geben E-Mail und Passwort in die Textfelder ein und klicken auf die Anmeldeschaltfläche“ ist eine Beschreibung, wie eine Story implementiert wird. "Der Benutzer meldet sich beim System an, indem er seine E-Mail-Adresse und sein Passwort angibt, die mit gespeicherten Aufzeichnungen verglichen werden", wäre eine bessere Benutzergeschichte. Der Zweck von Stories besteht darin, Anforderungen zu spezifizieren, nicht, wie sie implementiert werden.
Danke David. Um meinen Beitrag hinzuzufügen, PO entscheidet, „was“ getan werden soll, und das Team entscheidet, „wie“ es getan wird.

Ich liebe das Gherkin-Format . Die Details, die Sie beschreiben, wären Szenarien, weitere Details können in den Szenarioschritten erfasst werden.

Feature: Some terse yet descriptive text of what is desired
   As a ....
   In order ...
   I want ...

   Scenario: Some determinable business situation
     Given some precondition
       And some other precondition
      When some action by the actor
       And some other action
       And yet another action
      Then some testable outcome is achieved
       And something else we can check happens too

   Scenario: A different situation
       ...

In der Agile-Philosophie, wie von Thoughtbot, würden die Feature-Schritte im Gherkin-Stil in einem Paar-/Extremprozess zwischen Entwickler, Business Analyst und SQA/SDET geschrieben. Dieser Prozess würde in einer Grooming-Sitzung vor einem täglichen Scrum stattfinden. Tägliche Gedränge könnten die Geschichte neu ausrichten, wenn neue Dinge ans Licht kämen, würden sie aber nie vollständig schreiben.

Der Funktionstitel würde wie in Ihrem Beispiel Nr. 1 aussehen. Das Szenario würde durch Ihre Beispielzeilen Nr. 2 beschrieben. Obwohl Konzepte wie "Datenbank" wahrscheinlich nicht vorhanden sind, da sie für eine Feature-Datei zu implementierungsspezifisch sind. Solche Implementierungsdetails würden in Schrittdefinitionen festgehalten.

  1. „Ein nicht authentifizierter Benutzer gibt E-Mail und Passwort in das Anmeldeformular ein und klickt auf die Anmeldeschaltfläche“;

  2. "Der Server empfängt Anmeldedaten und prüft, ob sie Fehler enthalten"; (Ich würde dies entfernen, da es sich um einen Test handelt, der an anderer Stelle stattfinden sollte, wahrscheinlich in einem Komponententest.)

  3. "Der Authentifizierungsdienst gibt ein Authentifizierungstoken zurück und der Benutzer ist jetzt ein authentifizierter Benutzer";

  4. "Der authentifizierte Benutzer wird auf die Profilseite des Benutzers gebracht".

User Story in Scrum definieren: Wie spezifisch müssen sie sein? [Duplikat]
AntwortenHierDatenschutz-Bestimmungen1y, 0v