Frequently Asked Questions About User Stories

Members of my scrum team, training participants, colleagues, and various stakeholders involved in agile/scrum implementation projects repeatedly ask me the same questions about user stories. Although not considered core in scrum, user stories are helpful as an informal explanation of the needs, written from a customer’s perspective. They help the team better understand the value to that customer. 

Below is the list of questions and the corresponding answers that I share with everyone. I hope that this information is useful to anyone who wants to know more about user stories.

Q: What are user stories?

A user story is a brief description of any business need that is written from a user perspective during or prior to a backlog refinement or sprint planning session. A user story may include, but is not limited to, functionality, features, business rules, enhancement requests, bug fixes, infrastructure setup, or technical documentation. User stories can be almost any activity during a software development life cycle.

Q: How did user stories originate?

There is no specific date or incidence reported about the origin of user stories. However, existing literature suggests that user stories evolved during the process of establishing requirements that were originally documented in the form of use cases. Extreme programmers in the late 1990s made user stories popular in the software development arena. Newer agile frameworks, such as scrum and kanban, helped to widely promote user stories en masse.

Q: How do I write a user story?

The most popular format for writing user stories in many agile settings is as follows: As a user (of the system), I want to (action) so that (benefits of having this feature). 

For example, "As a student, I want to view my grades so that I know my performance."

Related Article: 5 Must-Haves For Great Scrum Story Writing

Q: Who's responsible for writing user stories?

There is no specific role responsible for writing a user story. Everyone involved in the software development process, from business stakeholders to agile team members, can write user stories. However, many stories are written during the backlog refinement session by the members of the development team, such as programmers, testers, and the analyst, as well as the product owner.

Q: What are the qualities of a good user story?

An ideal user story should be short, simple, and unambiguous. Many agile proponents consider Bill Wake's INVEST model as a basis for a good story. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Q: Do user stories require approval?

Unlike business requirements or documents in traditional software development approaches, no formal process exists for approving requirements in an agile environment. And user stories are not the only functionality, so it is the agile team members who accept the stories when most of them are confident of delivering that story within an iteration. Any doubts about a user story are clarified by the product owner in the scrum framework.

Q: What are the three Cs of user stories?

In 2001, Ron Jeffries proposed the concept of the three Cs: Card, Conversation, and Confirmation, to gain consensus on a story among the stakeholders in the agile framework.

• A Card story is written on a card, which is often a Post-it® note.

• A Conversation is a series of discussions among the development team and internal and external stakeholders to understand the depth of complexity and the value of the story.

• The Confirmation is to make sure that the conversation revolving around the stories has reached a conclusion.

Q: What are the differences between a use case and a user story?

Though use case and user story sound alike and many people confuse them as one of the ways of eliciting requirements, they are different in many ways, as follows:

• User stories and tasks: Team members perform tasks based on the set of activities for building a feature, as expressed in the user story. For example, the user story is this: As a home buyer, I want to view the listing of houses in my neighborhood so that I can make a short list of the houses I want to buy.
  
  Tasks for the story could be:

• Coding, using appropriate logic

• Integration of search and map APIs

• Development of test cases

• Integration with data sources

• Finalization of filter criteria

• User stories are relatively measured in sizes like S, M, L, XL, etc., or by using the Fibonacci sequence: 1, 2, 3, 5, 8, 13 . . . , based on the development complexity of stories. Tasks are always calculated in hours and are based on the level of effort each member has to put forth for each task.

• User stories and epics
  An epic is a set of similar features that sound like a story in the beginning, but when team members start analyzing it, they find it to be bigger than was previously thought. So they need to break it down into multiple stories. One way to differentiate an epic from a story is by checking whether it follows the INVEST model discussed earlier.