Understanding User Stories

User stories are commonly used in agile software development. I hear a lot of different ways on how to do them and the intent behind them.  Therefore, I wanted to share my understanding so far based on my agile journey. Let’s start with the history of a user story and why they were introduced.

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.

~http://www.extremeprogramming.org/rules/userstories.html

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

In experiencing multiple roles such as Product Owner and Scrum Master at different organizations, I have found what appear to be some common misunderstandings of user stories behind their original intent and the why. The above is a great opportunity to teach and mentor a team on the why behind user stories.

Some of the misunderstandings I have recognized include:

  • Development teams need all of the information upfront
    • As a product owner, you may spend a lot of time writing acceptance tests and items in a backlog vs. customer interaction
  • Developers and/or product owners don’t have a conversation with the customers
    • Lack of face-to-face and/or video conversations
  • Backlog refinement turns into conversations focused on trying to figure out what is needed and why or conversations become very how focused

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