What is User Story – Learn How to Create Good User Stories.

Almost all the Scrum teams I have worked with use “User Stories.” However, most of them are unaware of the origin of “User Story,” All of them think that user story is a “requirement.” In a sense, it could be correct, but that’s not what a User Story is.

What is a User Story?

In the simplest terms, a User Story is a way to express requirements. When a requirement/ functionality is described from the perspective of the user of the product or system or software, it is termed as a User Story.

A brief history and the origins of user stories

User Story or just Stories originated with Extreme Programming. In his book “Extreme Programming Explained” Kent Beck describes Stories as a primary practice used by the XP team. Within XP, the User Stories are written by the Customers as the functions or features that they want the system/software to do for them. It is often in the format of three sentences written by the Customer. The User Story always focuses on the needs and benefits of the user. Keeps the details like technology or implementation aspects out of it.

An Introduction to the World of User Stories

As stated above, a user story is a way to express any requirement from the user's perspective. And it could be as simple as a single sentence: “A student can register for the desired course.” Here, although, the details are not available. It simply says a student, a course, and register.

What should we do with it? And this leads to a discussion, a process of creating a common shared understanding about what this requirement is.

These conversations typically flesh out the details of the user story and often helps the developers and business to agree upon when we can say the user story is completed.  Ron Jeffries describes these three aspects of the User Stories as 3C’s. Card, Conversation, and Confirmation.

Card: In the good old days, user stories were written on a card (index/sticky notes). This did not have all the information describing the requirement but just enough to establish what the requirement is about. It is often used as a token to get started. This card then leads to the second C - Conversation.

Conversation: The business and developers now work together to establish clarity about the requirement through conversation. This happens multiple times till everyone has a common shared understanding about what the requirement is. Although this conversation is often verbal, notes are made, and criteria are established to determine when to call the user story complete. This established bar is the third C - Confirmation.

Confirmation: Despite all the conversation and documentation, there is always a possibility for uncertainties and assumptions. Confirmation refers to the final aspect which determines whether a user story is complete or not; whether the User Story does the intended functionality. This confirmation is also referred to as “Acceptance Criteria”. 

User Story Templates With Step-by-Step Guidance

In most teams that I have worked with, User Stories are not one-liners, as I expressed above. They have a very specific syntax as follows: As a role (who wants to do something) I want to do (the activity that needs to be accomplished) So that value (the goal that will be achieved) Example:  As a book lover I want to read book reviews So that I can decide to purchase a book This template was invented at Connextra, an early adopter of XP practices (source: User Stories Applied, Mike Cohn).

Types Of User Stories In Agile

• 1

  Functional User Stories: Functional User Stories are written based on the functional traits of the software and concentrate on the user and the value of the functionality offered to the end user.

• 2

  Technical User Stories: Technical User Stories provide support to functional user stories.

• 3

  Product Infrastructure: Product Infrastructure Stories assist with requested functional stories. This may be inclusive of new or revamped infrastructure.

• 4

  Team Infrastructure: Team Infrastructure stories help the team and their capability to deliver working software. This includes tooling, testing, metrics, design, and planning.

• 5

  Refactoring: Refactoring are technical user stories that identify codes that need refactoring. Refactoring is the process of improving the internal structure of code without altering its external behavior.

• 6

  Bug Fixing: Bug Fixing is a change to a product or system built to handle a programming glitch or bug.

   

• 7

  Spikes: A Spike is a technical user story where the estimation for the efforts required cannot be determined by the team. These are user stories requiring research on design and architecture helpful in fulfilling the functional needs of the end-user.

   

Spikes should be timeboxed in story points, and that timebox should contribute to the team's velocity for that sprint.  Spikes are estimated and demonstrated towards the end of the iteration, like other stories. Teams can use Spikes in numerous situations, such as- 

1. Estimating the latest features and capabilities to analyze the implied behavior offers insights to split them into minor measurable pieces. 

2. Find out the viability of epics by carrying out feasibility analysis and other activities.

3. Perform fundamental research to make them aware of a new technology or domain. 

4. Develop experience in technical and functional approaches, thereby minimizing risk and uncertainty.

Benefits of Good User Stories

There are many benefits of user stories, from delivering maximum value to enhancing collaboration. Let's have a look at the benefits below.  

1. Delivers the maximum value: Good user stories help in delivering the maximum value by concentrating on the immediate and smallest consumer requirements. Agile teams divide agile user stories into tasks and features that can be developed within days or hours. The Product Owner closely works on prioritizing the user stories based on parameters such as user value, risk, and business value to exponentially increase the value delivery in the initial sprints. Delivering maximum value increases the ROI and minimizes the investment since the product returns start to pay for the new functionality development.

2. Encourages Collaboration: Good User stories enable unimpeded collaboration between the development team, product owner, and client. Agile Teams directly talk to the customers to deliver optimum value to the customers. Good user stories require minimal writing which allows the development team to talk to the end users or the product owner while working on a user story in agile. This helps in unearthing business and technical insights that help address the customers' pain points.

3 Keeps the end users in loop: Since good user stories involve minimal writing, which helps in frequent interaction with the end users. This helps the development team understand the POV of the customer, pain points, and challenges that need to be resolved. As the users are in a loop, feedback is available regularly for the user stories that are DONE.

4 Building products in increments: Since user stories are split into small tasks, the product is built in increments, delivering the highest value possible. Product Increments allow for quick implementation and faster customer feedback. User stories can help add and remove new features.

5 Increase Transparency: User Stories written on Index Cards increase transparency among the Product Owner, Team Members, and stakeholders. These index cards are accessible to everyone, which ensures quick decision-making and better collaboration. Index Cards are not helpful in writing exhaustive documents.

6 Creates Shared Understanding: In conventional methodologies, the user stories are written and passed on to the development team to implement, resulting in substandard work. Things happen differently in Agile, where the Product Owner and Development team work together to distill, build, and divide the user stories.

Conclusion

Whenever any requirement is described from the perspective of the user of the requirement, it is termed as a User Story. A User Story follows 3C’s - Card, Conversation, and Confirmation. In addition, it is often helpful to have six attributes defined by the acronym INVEST - Independent, Negotiable, Valuable, Estimable, Small, and Testable, to be part of a user story.