How to write user stories?

How to write user stories?

User stories in Scrum are a short description of a particular product feature or functionality to be developed in the project. User stories are generally written from the end user’s perspective. This is important because Agile concentrates upon the requirements of people who are actually going to use a product or its features. This generally includes the end user, but stakeholders can also request “feature” based requirements if they feel it can enhance the product’s worth in the market. Sometimes, team members may feel a product feature can be further enhanced and made more “user-friendly” if it contains an added functionality. Therefore, they may request additional functionality to be included in a feature. Since user stories are important in Scrum, they should be written in a specific manner to ensure they are effective and useful.

How to write user stories? Stories can be written in many ways. Scrum is a framework, therefore, it does not prescribe exact definitions and rules about how activities should be actually carried out in a project. Rather it provides guidelines and Agile teams have to implement those guidelines in their projects to avail Agile benefits. Generally, user stories follow a “standard” format used by most professionals.

As a <user> I want <some activity> so that <some result or goal>

For example:

As a <Smart phone retailer> I want <to create an online smartphone gallery> so that <I can sell my smart phones>

Traditionally, user stories used to be written down on index cards and “pasted” on Scrum whiteboards so every team member could refer to them from time to time. Some organizations still follow traditional Scrum practices and use the whiteboards. Another option is to use computerized or digital Scrum tools or applications which offer features to create and manage user stories in the project.

What to focus upon while writing user stories

User stories are very important. It is important to keep a few points in mind while writing them. It is imperative that the stories be useful, developable, meaningful, and testable. Moreover, they should possess a certain “business value” once they are developed.

Should be valuable

Each story represents a product feature or a functionality. The feature should be “valuable” i.e. it should have a certain importance or “worth” from the market point of view. Meaningful user stories that result in useful and important functionality from the end user’s perspective carry more business value and make the product more “valuable”. Stories should be written such that the features they “include” are used more often by end users. They should have a certain “rationale” and justify why they are needed. When user stories carry a high value, the final product automatically assumes a certain “market worth” once all of the stories are integrated to form a working “release” of the product.

Target a particular “user”

Agile Scrum focuses primarily on end users and stakeholders. They decide how much a particular feature is worth and whether it should be developed or not. Stories are generally written from the end user’s perspective. However, if the development team feels a certain feature or functionality can increase the product’s worth or value, or if the functionality is needed for technical reasons, it can suggest stories and have them “accepted” by the product owner for development purposes. Each story should focus upon a specific end user or a customer. Stories can be effectively developed only if they are written keeping a certain “audience” or user in mind. That way, it becomes easy to define the “need” aspect, and how the story should ideally function. Moreover, each story, when designed, should have a specific objective and reason why it is needed, and why it should exist in the product backlog.

Have clear “acceptance criteria”

Stories are written to fulfill a certain objective. It is highly important to adjudge whether a particular user story can fulfill the purpose for which it has been developed. Acceptance criteria are unique conditions or benchmark parameters linked with each user story. After a story is developed, it is “checked” whether the “acceptance” conditions are successfully met, and whether the story functions in the manner as originally envisioned. It becomes meaningless if the story cannot satisfy the primary objective for which it has been written or designed. An acceptance criterion helps to determine if a story has been developed successfully, and is deployable or “shippable”. In Scrum, only shippable user stories should be developed through the daily sprints.

Should be testable

Scrum stresses upon bug-free functionality. Each story should be linked with certain acceptance criteria and should be testable. Stories designed to develop product functionality and features should be linked with proper technical “acceptance” criteria so they can be tested. Other stories concentrating upon documentation, creation of user manual, online help features etc. i.e. functionality which is not “codeable” but needed directly or indirectly to support, or complement, the development activity should be associated with certain quality approval parameters so that they can assume a certain standard and “quality” status once they are created. In short, every story – technical or otherwise – should be testable, and tested thoroughly before being accepted as “Done”.

Be small and easily developable

It becomes easy to manage and develop user stories if they are concise, or small. Smaller stories can be easily taken up for development during the daily sprints, and since they can be easily tested, the sprint cycle can sustain the team velocity through the development and delivery of small product functionality. Consistent and sustained product increments are possible only when user stories are small, manageable, and easily developable.

Described properly in details

A user story includes several “parts” i.e. its description, serial or index number, explanation, its business value in terms of story points, the “nature” of the story – whether the story is a “bug” to be rectified or a standard product feature/functionality – and any other information which can make the user story more “understandable”. Well defined and clearly stated stories can make development activity easy since the team becomes quite clear about how the feature is to be developed, and how the acceptance criteria should be ideally met to make the stories shippable.

Do you want to know to write user stories?