Before starting on tips to write user stories, let’s first understand what a User Story, who owns the User Story, the elements of the User Story, etc is.
What is a User Story?
A user story is the lowest unit of work in an Agile frame. It’s an end aim, not a point, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software quality written from the end-users or client’s perspective
Who owns the User Story?
While the Product Owner owns the user story, the all cross-functional team works on the product backlog. The Product Owner is responsible for addressing and arranging the product backlog containing its subjects and hierarchy.
Elements of User Story?
The most common format of a user story is as follows-
“As [a user persona], I want [to perform this action] so that [I can accomplish this goal]”
Apart from the typical format, here are a few things that make a user story unique:
1. A Unique Id: A special ID is used to distinguish a requisite specifically. When an Application Lifecycle Management( ALM) tool is used, this is the default trait that’s fixed by the team for all requisites.
2. Summary: This is the short or compressed title of the requirement
3. Description: The Description is the user story described in the standard user story format.
4. Acceptance Criteria: Acceptance Criteria is a set of predetermined requisites that must be completed before the user story can be pronounced complete. However, it SHOULD be constructed, If the demand is mentioned in the acceptance criteria.
5. Estimation: Estimation is the process of estimating the effort needed to finish a user story in the product backlog. maximum of the agile teams evaluates the user stories using story points.
6. Status: Status refers to the progress stage of the user story. It may begin with Open, In Analysis, Ready for Dev., In Dev, Idea, Defined, Refined, Planned, In Progress, Completed, Rejected, and Accepted.
An effective way of writing a user story is following INVEST concept
- I – Independent- Stories should be independent of one another so that each of them can be developed & Delivered separately.
- N-Negotiable- Stories should be able to modify
- V-Valuable- Story must ensure there is value being added to the customer.
- E- Estimable- Stories must be estimable and can be divided into task
- S-Small- Story should be small enough so that it should be completed in 3 to 4 days
- T- Testable- Stories should have acceptance criteria that can be tested to check if they fulfill the customer’s needs.
Types of User Stories
Below are some of the types of User Stories:
1. Functional User Stories: Functional User Stories are written predicated on the operational traits of the software and concentrate on the user and the value of the functionality trotted out to the end user.
2. Technical User Stories: Technical User Stories provide support to the functional user stories.
3. Product Infrastructure: Product architecture Stories support requested operational stories. This may be inclusive of substitute or changed structure.
4. Team Infrastructure: Team architecture stories assist the team and their capability to deliver working software. This includes tooling, testing, standards, design, and planning.
5. Refactoring: Refactoring is specialized user stories that identify codes that need refactoring. Refactoring is the process of perfecting the internal structure of code without modifying its accidental actions.
6. Bug Fixing: Bug Fixing is a change to a product or system constructed to handle a programming glitch or bug.
Benefits of Good User Stories
Writing good user stories has its benefits. Here are some of the benefits of writing good user stories-
1. Delivers the maximum value: Good user stories help in delivering the maximum value by concentrating on the immediate and lowest consumer conditions.
2. Encourages Collaboration: Good User stories enable delivered collaboration between the development team, product owner, and the customer. Agile Teams straightway talk to the clients to deliver optimum worth to the clients.
3. Keeps the end users in a loop: Since good user stories involve minimum documents which helps in frequent commerce with the end users. This helps the development team decide the POV of the client, ache points, and difficulties that need to be concluded.
4. Increase Transparency: User Stories written on Index Cards increase clearness among the Product Owner, Team Members, and stakeholders. These indicator cards are affordable to everyone which ensures quick conclusion material and better coordination.
Characteristics of Good user stories
- Must be user-centric
- Begin with an epic
- Be concise, simple, and precise
- Easy to test
- Contains the acceptance criteria for the testing team
- Mention INVEST criteria for writing a good user story
Tips for Writing Good User Stories
- Prioritize your Users
- Create Personas to write user stories
- Collaborate when creating user stories
- Keep your user stories short and simple
- Begin with Epics
- Filter the stories till they are ready
- Define Acceptance Criteria
- Make your stories accessible and viewable
- Stop overdependence on User Stories
Examples of User Sory
| S.No | User Stories |
| 1 | As a Banking Customer, I want to access/view a summary of my savings account, so that I know my balance and other details |
| 2 | As a Banking Customer, I want to transfer funds within my own accounts so that I can move some balance across my accounts |
| 3 | As a Net Banking application, I want to shake hands with another bank using a specific formatted XML so that funds can be transferred based on the customers’ needs |
How a User Story will look into JIRA board
Conclusion
Writing good user stories requires a lot of trials which will come by experiment. Since you now know the essentials, types, characteristics, benefits, and more importantly the tips to write good user stories, writing good user stories won’t be a herculean task anymore.
If you want to learn more you can refer to this blog.
If you want to know how to fail as an Agile Coach you can refer to this blog.
