Understanding User Stories

User stories are a common term used in agile software development. I hear a lot of different definitions of how to do them and what the end result is.  Let’s start with the history of a user story, why they were introduced, and then talk about ideal ways to use them.

The term user story in software development comes from XP (Extreme Programming).

User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
  User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
 One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face.


If we break this down, I find a couple of key points to understand. User stories are:

  1. Written by customers describing their needs
  2. Format of about three sentences (minimum detail)
  3. Drive the creation of acceptance tests (notice this doesn’t state the customer does this)
  4. Enough detail to make a reasonably low risk estimate
  5. Developers will go to the customer to get more detail face-to-face

Having been in multiple roles such as Product Owner and Scrum Master, I have found that there is a big misunderstanding of user stories at organizations. The above is a great opportunity to teach and mentor a team of the why behind user stories.

Some of the biggest issues I have faced are:

  • Development teams need all of the information upfront
    • As a product owner, you may spend hours writing acceptance tests and cards in a backlog
  • Developers don’t have a conversation with the customers
    • As a product owner, you may be frustrated because developers don’t want to spend time with customers and learn from them
      • This may not be the development team’s fault in that the system design and culture don’t embrace customer interaction
  • Lack of face-to-face conversations
    • This may be due to remote locations and/or it’s not embraced in the system design and culture

Different ways to implement user stories and solve for some of the issues above:

  • Try having minimum detail for user stories in your backlog
    • As a < type of user >, I want < some goal > so that < some reason > ~Mike Cohn
  • Try bringing the development team to the customer through refinement sessions and sprint reviews
    • Focus on having a valuable conversation
  • Try writing acceptance tests as a product development team (developers and business people)
  • Try estimating items with minimum details
  • It’s OK not to know everything about an item as being agile requires accepting changing requirements even late in the process for the customer’s advantage

What are your thoughts on using user stories? What things have worked well for you? What problems have you faced with user stories?

Please leave a comment below.

Leave a Comment

Copyright © 2020 Envision Agile