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.
1. A 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
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 i.e. “As [a user persona], I want [to perform this action] so that [I can accomplish this goal]”
4. Acceptance 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.
5. Estimation: 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.
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.
Learn to write great user stories: Enroll for the PSPO Certification Training today.
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. 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 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. 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 in the addition and removal of 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. This collaboration helps in the shared understanding of two things-
1. Prioritize 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.
2. Create 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.
3. Collaborate when creating user stories: Don’t mistake a User Story to be a specification tool; rather, treat it as a communication and collaboration tool. If user stories are written and handed over to the development team, then it defeats the sole purpose of user stories. The Product Owner and the development team should interact with the users and collectively create user stories. Collaboration between the Product Owner and the development team creates shared understanding.
4. Keep 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.
5. Begin 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.
6. Filter 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.
7. Define 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.
8. Use 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.
9. Make 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.
10. Stop 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.
|Scrum Master (PSM) Training||Leading SAFe® 5.1 Training with SAFe® Agilist Certification||Implementing SAFe® 5.1 Training with SPC Certification|
|Product Owner (PSPO) Training||Certified Agile Coaching (ICP-ACC) Training||Agility in the Enterprise (ICP-ENT) Training|
|Professional Scrum with Kanban™ (PSK) Training||Advanced Scrum Master (PSM-II) Training||SAFe® Lean Portfolio Management (LPM) Training|
|Agile Fundamentals Bootcamp (ICP) Training||Advanced Product Owner (PSPO-A) Training||SAFe® Agile Product Management (APM) Training|