10 Tips to Help You Write Great User Stories

Writing good user stories is an art that comes by practice and not by simply wishing. User Stories form a vital part of developing the functionality of a product. If you’re looking for tips for writing good user stories, then this blog post is for you.

Let’s take a tour of the basics of User Stories before reaching the focal point of today’s content. 

What is a User Story?

User Story is a tool used in Agile to record the description of a software product from the end-user perspective.  User stories are further divided into manageable pieces of work, often called as tasks. 

Who owns the User Story?

While the Product Owner owns the user story, the entire cross-functional team works on the product backlog. The Product Owner is accountable for managing and organizing the product backlog, including its contents and ordering. 

Elements of a User Story

• 1A Unique ID: A Unique ID is used to identify a requirement specifically. When an Application Lifecycle Management (ALM) tool is used, this is default attribute that is fixed by the team for all requirements
• 2Summary: This is the short or compressed title of the requirement
• 3Description: The Description is the user story described in the standard user story format i.e. “As [a user persona], I want [to perform this action] so that [I can accomplish this goal]”
• 4Acceptance Criteria: Acceptance Criteria is a set of predetermined requirements that must be fulfilled before the user story can be marked complete. If the requirement is mentioned in the acceptance criteria, it SHOULD be built.
• 5Estimation: Estimation is the process of estimating the effort required to complete a user story in the product backlog. Most of the agile teams estimate The user stories using story points.
• 6Status: 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.

Different Types of User Stories

• 1Functional 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.
• 2Technical User Stories: Technical User Stories provide support to functional user stories.
• 3Product Infrastructure: Product Infrastructure Stories assist with requested functional stories. This may be inclusive of new or revamped infrastructure.
• 4Team Infrastructure: Team Infrastructure stories help the team and their capability to deliver working software. This includes tooling, testing, metrics, design, and planning.
• 5Refactoring: 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.
• 6Bug Fixing: Bug Fixing is a change to a product or system built to handle a programming glitch or bug.
• 7Spikes: 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. 

10 Tips for Writing Good User Stories

• 1Prioritize your Users: User stories should always be written with a ‘User-first’ approach. It should describe how the end user is going to use the product. User stories are helpful in understanding the accurate functionality needed by the user. The Product Owner and Development team should interview/talk to users and then write user stories that are customer-centric.
• 2Create Personas to write user stories: Creating agile personas is one of the most widely used methods when it comes to writing user stories. Personas are fictionalized representations of typical users of your goods, services, website, and so on. They are used to develop a picture of your consumers, including their preferences, traits, decision-making processes, and so on, by creating profiles of typical users. This will be helpful in determining the actual problems your users might be facing.
• 3Keep your user stories short and simple: User Stories should be written in simple and lucid language. Leave out the jargon and ambiguous terms. Include only the important information and omit the rest.
• 4Begin with Epics: An Epic is a large user story that is broken down into user stories that contain a larger strategic objective. It is highly useful in receiving feedback on product increments and prototypes. Epics help you to figure out the product functionality without going into the details. This helps in articulating new products and features and helps in understanding the best ways to address user needs. Epics greatly reduce the time and effort for combining new insights.
• 5Filter the stories till they are ready: The Development Team must have a shared understanding with respect to the user stories. The user stories should not be too long and must contain acceptance criteria. The user stories should be split until they are crystal clear, practical, and testable.
• 6Define Acceptance Criteria: Acceptance Criteria is a set of predetermined requirements/conditions that must be fulfilled before the user story can be marked complete. If the requirement is mentioned in the acceptance criteria, it SHOULD be built. It helps the team understand the conditions that the team has to be fulfilled to mark the story as ‘DONE’. When epics are split into smaller stories, it is mandatory to determine the acceptance criteria. This marks the product ready to be released and demonstrated to the end users. As a thumb of rule, keep 3 to 5 acceptance criteria.
• 7Use Paper Cards: Paper Cards may sound strange, but they were used in Extreme Programming(XP). Paper Cards help in better collaboration, can be easily stuck on the wall to inspect for regularity and perfection and to visualize dependencies. And lastly, it is low-cost and easily usable.
• 8Make your stories accessible and viewable: Your stories are meant to communicate information. By making it private and restricting visibility, you are hindering communication and collaboration. Display your stories on the wall or use a tool for everyone to see, as this will inform everyone about the changes in the product.
• 9Stop overdependence on User Stories: Overdependence on User Stories sets the product for failure. A product’s success shouldn’t entirely rely on User Stories. It takes more than user stories to create a superb user experience. User stories aren’t made for articulating user journeys and visual design. Use story maps, workflow diagrams, storyboards, sketches, and mockups. Lastly, use UML for defining technical requirements since user stories aren’t the best tool for it.

Characteristics of Good User Stories

• 1Should portray maximum user value
• 2Must be user-centric
• 3Begin with an epic
• 4Be concise, simple, and precise
• 5Must contain supplementary documentation and information if required
• 6Should be detailed enough to showcase value and basic enough to build in a single iteration
• 7Should be created by including inputs from all the stakeholders
• 8Flexible and modifiable without affecting other user stories negatively
• 9Easy to test, Contains the acceptance criteria for the testing team
• 10Mention INVEST criteria of writing good user story

Benefits of Good User Stories

• 1Delivers the maximum value: Good user stories help in delivering the maximum value by concentrating on the immediate and smallest consumer requirements. Agile teams divide 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.
• 2Encourages 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. This helps in unearthing business and technical insights that help address the customers' pain points.
• 3Keeps 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.
• 4Building 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 in the addition and removal of new features.
• 5Increase 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.
• 6Creates 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.