Defining user story in Scrum: how specific must they be? [duplicate]

Question

As the title suggests: for example, the following user story too generic?

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

Or, should I use more detailed user stories, like the following ones?

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".

It seems the more it is specific, the more we understand the part of codes required ( 1)"textboxes", 1) "login button", 3) "database", ...).

Which is the correct way between these two?

Answer 1

User stories should have enough basic information like who (type of user) wants what functionality and why is the functionality needed. Also, what is his or her success critrion for the story. Details should be avoided in the user story as they will be discussed as part of sprint planning meeting. it is very tough to strike the right balance but an experienced scrum master can really facilitate the productive discussion. As a rule of thumb, it should be specific enough so that the story has a good chance of being completed in a scrum.

That said, the example you are giving above seems to have some tasks that are defined and decided by the team members. User stories should generally come from Product Owners (PO)

Answer 2

I love the Gherkin format. The detail you describe would be scenarios, more detail can be caught in the scenario steps.

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
       ...

Answer 3

In the Agile philosophy, as by Thoughtbot, the Gherkin-style feature steps would be written in a pair/extreme process between Developer, Business Analyst, and SQA/SDET. This process would happen in a grooming sessions, prior to any daily scrum. Daily scrums might re-align the story, if new things came to light, but would never write it entirely.

The feature title would look like your example #1. The Scenario would be described by your example #2 lines. Although, concepts like "database" probably not not be present, as they are too implementation specific for a feature file. Such implementation details would be held in step-definitions.

1. "An Unauthenticated User enters email and password in the login form, and clicks the login button";

2. "The Server receives login data and check if they contain errors"; (I would remove this, as it is a test that should happen elsewhere, probably in a unit test)

3. "The authentication service returns an authentication token, and the user is now an Authenticated User";

4. "The Authenticated User user is brought to the user's profile page".