1

This question already has an answer here:

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?

marked as duplicate by Todd A. Jacobs, Mark Phillips Dec 29 '14 at 3:22

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4

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)

  • I agree here. The examples in the question are not good stories. "User insert email and password in the textboxes and click the login button" is a description of how a story will be implemented. "The user will log into the system by supplying their email and password, which will be checked against stored records" would be a better user story. The purpose of stories is to specify requirements, not how it'll be implemented. – David Arno Dec 19 '14 at 12:31
  • Thanks David. To add to my post, PO decides 'What' is to be done and the team decides 'How' it will be done. – pksnj Dec 23 '14 at 14:51
3

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

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.