10 Tips to Write a Good User Stories
Scrum Framework is one of the most implemented frameworks in Agile in many organizations. The term 'User Story' is usually associated with the Scrum Framework though it is not formally defined in Scrum. The professional needs to understand the meaning and importance of Agile Project Management and business goals. A User Story is a general and informal explanation of a software feature that is visualized from the user's perspective. A User Story is much more than a software requirement. It is how the Developer understands how a specific software feature will enhance the user's experience.
Agile Methodology's frameworks have always prioritized the customer's needs before any other technicalities. The User Story could be thought of as the customer's needs, and the Agile team's primary focus always revolves around the User Story. It is a language from the user's end, which helps the Developer gain ideas to improve the product by adding product increments. After looking at the User Story, the Agile Developer can understand why they are building a particular product and how it adds value to the customer. Hence, one of the Agile Project Management's core components is User Stories that enhance the team's creativity and collaboration by building a better product.
What does Agile User Stories mean?
A User Story is an end goal that is formulated by the user of the software. It forms the least unit of work in the Agile framework. The software developer is expected to meet the User Stories requirements, which is defined by the user in non-technical terms. The User Story can be explained by thinking about it as a general and informal explanation of a product increment or software update. The end-user of the software defines the User Story from their own words and explains what increment or changes they need in the current product. User's stories, one of the chief objectives is to learn and collaborate a piece of information and deliver specific content to the customer. The organization members, such as colleagues who depend on the Scrum Developer, can also act as an internal customer. User Stories should not be thought of as an instruction manual that contains the details of building the software feature. It is just a simple language that sketches the result desired by the customer. Epics are large work items that have to be broken down into a set of stories, and multiple epics are piled together to form an initiative. These larger structures ensure that the Developer's day-to-day work contributes to the organizational goals built into epics and initiatives.
10 Tips to Write Good User Stories
As we understand how important a User Story is for any Developer, we now learn ten tips about writing good User Stories and what professionals have to focus on while writing User Stories.
1. Keep Users at Priority
As the name suggests, a User Story should always be written by the user's perspective. It describes how a person or the user is going to employ the product for their benefit. User Stories are also helpful in understanding the specific function required by the user, such as if a customer wants to search any electronics item on the application or manage a booking ticket of a movie, etc. This gives the Developer a clear idea about the specific function they have to focus on.
Suppose the Developer does not know the user's perspective and cannot understand how the developed product will benefit the user. In that case, they simply should not write any User Stories. It is advised that they should initially research the users for the development and, if possible, interview a few users to understand how a particular feature would make a difference in the product as a whole and how they will be benefited from it. However, if the Developer proceeds with facts and beliefs about what they think and not the empirical data, they can most likely develop products that are not required by the customer.
2. Discovering the right stories using Personas
One of the most implemented methods of explaining and knowing the customer's needs is by writing personas. A persona has a name and a picture but is a fictional character and does not exist in the real world. This persona created would have individual attitudes, behaviors, and characteristics relevant to the software users. In particular, the persona wants to achieve a goal or solve a problem that they are facing with their current product. The development gets an idea about the personal's issues and goals and understands what the real-life users face problems with. The team can also discover new and good User Stories that will help solve the customer's problems.
3. Should collaboratively write stories
Stories are never handed off to the Developer and should not be disposed of. It should act as a tool for collaboration and communication between the users and the developers, and other team members. It should not be treated as a specification only. It is how the Developer and the Product Owner express their ideas to each other and write a User Story that would benefit the users and enhance product quality. By writing the User Stories collaboratively, such as in a Product Backlog grooming process, it takes the communication between the Agile team to the next step and aids in forming better User Stories.
4. Writing concise and simple User Stories
A simple and easily understandable User Story is all that is required while writing the User Story. It should not be written like an instruction manual with all the steps to build the software feature. Terms that are ambiguous and may confuse the team members should always be avoided as the User Story should form a means of communication and not a barrier. Express User Stories in active voice and not passive as it feels that the opinion or the idea is from the first person's perspective. Always exclude words that do not add value to the User Story and write words that are simple and convey the message loud and clear.
5. Write User Stories by starting with epics
Several User Stories ranging through a period form an epic, which is a significant and sketchy story. As the prototype of a product is released, the Developer gets the feedback from the customer and bases the next product increment or User Story on the previous feedback. Using epics for product development allows the team to outline the product's functionality without actually sticking to the details. As new features and products are introduced in the market, epics help describe them through a rough scope. The team could quickly learn the user's needs and requirements with the help of epics. Integrating new insights requires time and effort, which is significantly decreased by using epics. Epics also help the team trace back the feedback to the right story as many levels may pile them, and it is difficult to trace back to a specific one.
6. Have to refine stories until they are ready
The Developer should have a shared understanding of the story's meaning. The story developed should not be lengthy and should contain an effective way to decide whether the story is fulfilled (i.e., should have a proper Definition of Done). The User's Stories have to be refined until it is ready. By ready, it means that the story should be clear, feasible, and testable. Hence, all the epics must be broken down into smaller and detailed stories until they satisfy these criteria and become a little straightforward, specific User Story.
7. Adding Acceptance Criteria
An acceptance criterion complements the story's narrative as it allows the team to discover the conditions that have to be fulfilled so that the story is done. As the group breaks the epics into smaller stories, it is essential to add acceptance criteria. These criteria enrich the story and make it a more testable and precise User Story. It also ensures that the story can be demoed or released to the users and other Stakeholders. Usually, it is advised as a thumb rule, that a detailed story should have at least three to five acceptance criteria.
8. Using Paper Cards
Using paper cards was a traditional method in early XP literature where story cards were used instead of User Stories. User Stories emerged recently in Extreme Programming (XP). Going back to the roots, we can use paper cards to write User Stories, as this approach primarily provided three benefits. The first reason was that paper cards were cheap and easy to use. Second, they facilitated collaboration among the team members as everyone has a chance to introduce their idea and write them. And the third reason was that the paper cards could be easily grouped on the wall or table to check for completeness and consistency of the developed User Story. Also, dependencies could be visualized through this technique. Even if User Stories are stored electronically, the paper cards method could be a new chance for the team, and it could be worthwhile to try out this method.
9. User Stories should be Accessible and Visible
User Stories are a means to communicate information about the product increment. It should not be hidden in a network drive or a licensed tool. It should be made visible for everyone to see, such as putting it up on a wall. These User Stories should be accessible for everyone, as effective collaboration requires everyone to be a part of the team. This communication could only happen when everyone on the team is informed about the User's Stories and the changes in the product.
10. User Stories should not be relied upon solely
A product's success should not be considered based on the User's Stories. Creating an excellent experience for the users requires more than writing the User Stories; it depends on user interactions and journeys, the visual design, and the product's non-functional properties. As a result, we get a holistic description of the product, making it simpler and more comfortable to identify risks and assumptions. It also increases the chances of creating a product with the right user experience.
Also, technical requirements cannot be entirely described by the User Stories as they only describe the product from the user's perspective. In this case, technological developments could be useful as it captures the product's technical requirements that communicate how an architectural element like a component or service should function. Modeling language such as UML could be used in these scenarios.
Conclusion
User Stories form an essential structure for the Developer to work on in most of the Agile Frameworks. It provides the team with a perspective of the product increment from the user's end. This gives the product Developer a sense of clarity to understand the user requirements and design the product efficiently. A few of the tips on writing great User Stories are that the team has to always keep the user's needs as a priority. Different personas, which are fictional characters, can also help the section form a great User Story. Creating the User Story collaboratively, using paper cards, and keeping the User Story short and concise are few tips for writing a good User Story. The team is also advised to start with epics and refine the User Story until it is clear and feasible. Acceptance criteria are also an integral part of formulating a User Story. Hence, by implementing these tips, team members can write quality User Stories that would ultimately enhance product quality and increase customer satisfaction.
References
- https://www.atlassian.com/agile/project-management/user-stories
- https://dzone.com/articles/10-tips-for-writing-good-user-stories
- https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3127/10-Tips-for-Writing-Good-User-Stories.aspx
- https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
