Product Management 101 Tips for Writing Good User Stories

Product Management 101 Tips for Writing Good User Stories In the world of agile development, user stories have become a central part of product management. But the concept of user stories can easily be misunderstood to be just another way of outlining the requirements for a product or a service. If you don’t pay attention to writing user stories, you might end up wasting your time and be left with ill-fitting stories. © pixabay | UnsplashIn this guide, we’ll explain the concept of a user story and examine the qualities that make up a good user story. We’ll then provide you with six tips for writing exquisite stories and finally detail the limitations of a user story in product management.USER STORY IN A NUTSHELLUser story is a concept used in software development and product management. It is a description of the user using the products, as well as an explanation on what the user wants from it and why. In it’s essence, a user story helps to create a more simplified requirement description.User stories are essential for building your service, whether a software or a product, as they help identify the needs of the user. Instead of using lengthy requirement specifications, user stories can help capture the core elements of the functionality.To put it shortly, a good user story will capture:The who â€" who is using the product or service?The what â€" what are they trying to achieve with the pro duct or service?The why â€" for what purpose are they using the product?One of the simplest user story templates would look like this:As a [who], I want to [what], so I can [why].Therefore, a user story for a recruitment website might be:As a job seeker, I want to search for a job, so I can get on the career ladder.User stories are generally used as part of agile development strategies, with the product manager taking charge of the creation. Nonetheless, it’s a good idea to ensure everyone in a team knows how to write user stories and to use them for the benefit of the project. WHAT MAKES A GOOD USER STORY?While the concept of a user story is straightforward, writing good user stories is not as easy as you might think. There are good and bad user stories. Before we look at the tips for writing good user stories, it’s beneficial to first examine the reasons behind a good user story.One of the most commonly cited ways to assess the strength of a user story is with the INVEST acron ym. The acronym was first introduced by Bill Wake, the author of eXtreme Programming Explored, and it’s a great method to test if your user story is well written.INVEST stands for:Independent â€" each feature should be as independent as possible.Negotiable â€" user stories are not detailed specifications, but tools for the team to discuss and collaborate.Valuable â€" user stories must provide value to the user of the product or service.Estimable â€" user stories don’t need to include too much detail, but they must provide enough information so that you can make estimations.Small â€" user stories are not big, but small and concise.Testable â€" the wording must allow the user story to be tested.When writing user stories, it is helpful to keep the above acronym in mind. It can help you capture the essence of a good user story: it’s a story, not a task.Finally, it’s important to understand what a user story is not supposed to be in order to create a solid story. You are not writ ing a detailed specification of the product or service, when you are creating a user story. A user story will start a conversation and help move the team forward, not end it as a final description.TIPS FOR WRITING GOOD USER STORIESIn order to ensure your user stories follow the INVEST concept and help you fulfill the business needs, keep the below tips in mind when writing user stories.Research your userIt’s essential to first understand who the user is. After all, user story should be written from the user’s perspectives and you can’t capture the what and the why, if you don’t start with the who.Interview and observe the user to understand who they are and how they are using the product. You can’t write a good user story by speculating on the user and their ideas â€" you need to research these before. In short, you are examining the functionality of the product and service in terms of the user.Therefore, you want to create user personas as a way to capture the user in mor e detail. A user persona can consist the following elements:A name and a pictureRelevant characteristics and personality traitsAttitude of the personThe benefit of using the product or serviceLet’s consider the following examples of a user story:As a user I want to be able to access job postings so that I can find work.As a job seeker I want to be able to access job postings so that I can find work.The examples are similar in nature, but the first doesn’t define the user well enough. We don’t know the user persona and we cannot make further assumptions, when he is only referred to as ‘the user’.On the other hand, the latter example defines the user in detail and instantly gives us more information about what the user needs.Learn from Google Ventures on how to conduct a user test. Start with epicsYou should start the process of writing user stories by creating epics. An epic is a big and sketchy story, which will break into smaller, separate user stories over time.By creati ng epics first, you can develop an understanding of the functionality better and leverage user feedback on the prototypes. With an epic, you’ll learn about the needs of the user and how to address them.As you craft sketchy epics, you can start creating the detailed user stories. In short, epics can help you understand the user persona and parts of the functionality they are looking for. For example:As Kate, I want to tell people about big events at work.As you learn more about the what and the why, you can start forging the above information into a more testable and clear user story. For instance:As product manager Kate, I want to show an overview of the upcoming events at work, so that I can promote them.Focus on the goalThe key to a good user story is to focus on the specific goal. If you are able to identify the goal for the user, then you are going to understand the functionality of your product or service better.There are two reasons goal matters in user stories. First, they ensure you are solving an actual problem with the user story and not simply assuming things. Second, they provide you the tools for testing the user story and understanding when the user needs are satisfied.Therefore, in order to write a good user story, you need to consider why the user wants the specific feature or product.For instance, the below example of a user story does not explain the value of the system in a clear manner:As a customer ordering groceries, I want to view my previous shoe orders on the website.If you read the example, you are left asking what is the reason for the user wanting to see the orders. What is the value in being able to view the order history?A much better user story would therefore be:As a customer ordering groceries, I want to view my previous shoe orders, so that I can re-order my favorite products faster.This time you know what’s driving the user need. You are able to understand the customer behavior better and ultimately to test the user story ’s viability.Keep it concisePay attention to the language you use when you write user stories. Your user stories must be easy to understand. After a person reads a user story, you don’t want them to be left with confusion.To achieve the right kind of tone you want to use an active voice and easy words. Jargon and a formal tone are not suitable for a user story. For instance, consider the following example of a complex and badly worded user story:As a customer, I need to save, print and email my lists on the platform, and then send the requirements for the shop.The above is hard to read, it’s not concise and it doesn’t answer the question of why. In addition, it also includes a larger story and would be much better as an epic than a user story.An example of a concise user story would be:As a customer of the food delivery service, I need to save my item list, so that I can use it as a starting list at the store.You might also notice from the too examples that while the first e xample included a lot of detail, the latter example removed certain elements. In the above example, you probably would come up with a number of different user stories from the first epic.While you don’t want the user story to include too much information, you also don’t want it to be too broad. Consider the example of:A member can manage tasks.While the user story is short enough, it’s vague and doesn’t reveal anything interesting or valuable to the reader. Instead, you’d want to include more detail and say:As a team member, I can view or hide the tasks so that I can manage my account.The example template mentioned in the introduction is one of the simplest templates to use. Whilst it is often the preferred format, you can experiment with other styles, as long as you pay attention to the length and clarity of the format.Include acceptance criteriaA user story should always include acceptance criteria. The acceptance criteria are also known as Conditions of Satisfactions (C oS) or Definition of Done (DoD). This essentially helps underline the conditions for job achieved and helps with testing the user story.Acceptance criteria can be used as a checklist to check the product or service has met the user’s need. You can create the acceptance criteria by asking questions such as:What if?Where?When?How?Your project should include between two to five acceptance criteria. You should create the list during a meeting with the product or service owner and the development team (if separate).For example, if you are developing a service for registering membership, you’re acceptance criteria for user stories would be:The user knows how to register on the websiteThe user knows how to confirm registrationThe user knows where to solve registration problems Once you have the acceptance criteria, you can use it to test and support your user story. Remember the criteria is not there to restate the story, incorporate in new stories or contain new workflows.For instance , if your user story is:As an app user, I want to delete messages, so that I can control my phone memory.Bad acceptance criteria for the above would be something like:The user wants to select any message, remove the text and save another version of the text.The problem with the above criteria is that it adds new workflows and stories to the existing user story. The user story doesn’t, for instance, mention anything about the ability to save modified messages.Make it a team effortAs mentioned in the introduction, user stories are often the responsibility of the project manager. But the effort of creating them should solely rely on the hands of a single team member. The best user stories are created as a team effort because it guarantees they capture the experience and functionality better.Roman Pichler recommends writing user stories as part of the backlog grooming process, as this guarantees the whole team can provide input for the stories. Furthermore, approach the writing proces s more through communication rather than implementation. You want the team to discuss the ideas, provide feedback on existing epics and data, for instance.Even if you can’t have the whole team and all the relevant stakeholders meet at the same time, you should gather feedback from everyone.Below is a great video on how to brainstorm user stories together with your team; outlining the steps, you need to make the most of the collaborative effort: KNOW WHEN A USER STORY IS NOT ACCEPTABLEIn order to write good user stories, you should understand they aren’t always the right or the only format you should use as part of product management. There are a handful of business needs, which cannot be appropriately understood through a user story.A user story might not be adequate format, if the product or service at hand is focusing on:A change requestA constraint such as technology stack or database useA technical requirement such as a security standard complianceFor example, if you only ne ed to capture a technical requirement, a user story won’t help communicate the problem and the solution. Ronica Roth, an Agile coach and consultant with CA Agile Central Software, said in her blog post that by trying to make a technical task into a user story, “you often do not end up with working software at the end of each iteration, and you lose flexibility in prioritization”.If the why is a technical capability, you are generally better off avoiding a user story. This is because the technical capability is not going to provide value to the end user. Consider the following attempt of a user story with a technical capability as the why:As a tester, I want to have detailed plans so that as the system is completed, I will be able to test it.Overall, user stories are just a part of a good user experience. But you also want to add in other techniques such as story maps and mock-ups. Remember user stories are not detailed requirement stories, but aimed at capturing the functional ity of the product or service.FINAL THOUGHTSUser stories are an essential part of product development. A good story can help understand the needs of the user and the ways the product or service can help fulfill them. It can guide product development by helping it focus on functionality.Although the concept and purpose of user stories is simple, writing a good user story isn’t necessarily as easy as it sounds. Apply the INVEST approach to your user stories and remember to write the stories from the user’s perspective. Approach the process through communication and collaboration and be aware of the limitations of user stories.Image credit: pixabay | Unsplash under  CC0 Public Domain.