How to write YOUR perfect User Story

1. Intro: Hi there. My name is Adam. I'm a Product Manager and I'd like to speak to you about how to write your perfect user story. Yeah, That's right. Your style, your personality, your passion and commitment, your team, your stakeholders, your product, and your user story. Because there's no such thing as a universal template that makes it all perfect and that applies across the board. If you think that you've achieved perfection in writing your user stories, you might have a surprise when you will switch teams for projects. With each and every interaction with each and every new feature, your approach will slightly change and that's okay. You are the one who needs to adjust so that the story right, reaches the desired aspect in terms of clarity and granularity and appeal. So everyone's level of understanding. The same user story that you're writing needs to speak the language of the development team who are technically savvy, but it must also speak the language of the business owners who may or may not have a technical background. My definition of a perfect user story has its foundation in the following statement. If you take a stranger for model the street and show them the user's story that you've written. They shouldn't be able to understand it. It should be fairly easy for anyone to wrap their heads around the requirement, the context, and the functionality that will be born as a result of implementing this particular user story. So what we're gonna be speaking about his guidelines, pointers, tips and tricks, and everything that you need to know in order for you to be able to write your perfect user story regardless of the team, the project, or the industry for that matter. 2. How to write your perfect user story: Hi there. My name is Adam. I'm a Product Manager and I'd like to speak to you about how to write your perfect user story. Yeah, That's right. Your style, your personality, your passion and commitment, your team, your stakeholders, your product, and your user story. Because there's no such thing as a universal template that makes it all perfect and that applies across the board. If you think that you've achieved perfection in writing your user stories, then you might have a surprise when you will switch teams for projects. With each and every interaction with each and every new feature, your approach will slightly change and that's okay. You are the one who needs to adjust so that the story right, reaches the desired aspect in terms of clarity and granularity and appeal. So everyone's level of understanding. The same user story that you're writing needs to speak the language of the development team who are technically savvy, but it must also speak the language of the business owners who may or may not have a technical background. My definition of a perfect user story has its foundation in the following statement. If you take a stranger from model the street and show them the user's story that you've written. They shouldn't be able to understand it. It should be fairly easy for anyone to wrap their heads around the requirement, the context, and the functionality that will be born as a result of implementing this particular user story. So what we're going to be speaking about his guidelines, pointers, tips and tricks, and everything that you need to know in order for you to be able to write your perfect user story regardless of the team, the project, or the industry for that matter. But first things first, what is a user story? A user story is a clear representation of a requirement, illustrating the user's perspective and articulating how a particular functionality will deliver a specific value to the customers. It is written as a story using a specific format, but in plain English. And in such a language that any human can easily read and understand with no prior contexts or additional information. How granular is in fact a user story? Well, you've got project level at big level, feature level, and then you've got user stories. So they are basically the single most granular expression of requirement. However, as granular as it may be, the user story still needs to define a fully testable and deliverable piece of functionality. No matter how small. Why do we use user stories? We use them to translate business needs into user-focused functionalities. We use them to create a common understanding of what we want to build so that we end up building the right thing and how it will be built. So that we end up building it right? We use them to have a single source of truth and a more standardized way of structuring and communicating with the team, but also outside the team with our internal or external stakeholders. And last but not least, we use them to set up expectations and create habits. What are the benefits of better user stories? Faster delivery of higher customer satisfaction, better learning curve, quicker decision-making, less waste. So build the right thing and build it the right way. Or else questions will arise and not the good guy and the bad kind. That will soon translate into uncertainty, lack of confidence, questioning and push back all the nasty things that will badly damaged your relationship with the development team. Not to mention the delays, the late hours on Friday nights at the end of the sprint, the multitude of bugs that will inevitably creep into the product that you're supposed to be nurturing. And last but not least, barely solving for the need and Load to know customer satisfaction. Invest in good user stories because user stories need to be independent so that they can be worked on without any type of dependencies negotiable, because a user story is not a contract for a feature. Valuable, meaning that it must deliver value for the customers, estimable to a reasonable level of approximation, small sized, such that it fits into an iteration, then testable so that the conditions of success can be tested. Let's talk a bit about the anatomy of a user story. You can have different types of users stories. You can have regular user stories. You can have technical user stories. You can have spikes, which are basically. Investigation user stories and so on. Now what makes a good user story? Well, to begin with, a user story has a title. The title must be concise, clear, and intuitive. Think about newspaper headlines. That's what the title is to your user story. Then it's best to provide a bit of a context as to why is it that we want to implement this piece of functionality? What value it brings to our customers, and what is the need, It's souls. The reasoning behind this is that the development team can not work in isolation. They don't just sit around in a bubble waiting for someone to feed them user stories. Without them understanding the full context and the implications. The better they grasp the context of requirements, the more capable there'll be to come up with a better technical solution with a valuable feedback for the business and so on. So how do we express that context? Well, as part of the anatomy of a user story, you begin with a famous as a, I want. So that formula. Let me give you an example. If the title of my user's story is the user can perform a search on the web site, then the expression of the context, would it be, for instance, as a website user, I want to be able to perform a search on the web site so that I can find the item that I'm looking for. Then you've got the acceptance criteria section. This is where you write down the actual requirements because the context is not the requirement. It is a mirror high-level description of the reasoning behind the requirement. Watch you will write down in this section, the development team will turn into reality. The developers will write the code. The testers will test the functionality afterwards. And the product owner or the business analysts will perform the UAT user acceptance testing based on those specific requirements. So what should the acceptance criteria look like? Well, ideally, you would structure it in scenarios. For example, scenario number one, scenario number two, and so on. Each of them with a specific title and composition. And this is where we use the other famous body part of a user story, the given when then sequence. The given is the prerequisite. It describes what you already need to have in place. By the time you get to this step. The when is the trigger. It shows what needs to happen. In order to determine a specific behavior. Then is the expected behavior. It illustrates what should happen as a result of a specific trigger. Following our previous example, with the customer who needs to be able to perform a search on the website. Our first scenario and the acceptance criteria would sound like this. Scenario number one, the title would be Search option is available for the user. Then we've got the given when then sequence. So let's see. Given that the user has access to the website, when the product's page of the website is displayed, then the search module is available in the top right corner of the screen. So what have we done here? First, we've described the prerequisite given that the user has already access the website. Why? Because if the user doesn't access the website, then there's no functionality to speak of. Then we specify the trigger when the product's page of the website is this plate. Why? Because the development team needs to know when this newly implemented piece of functionality should be available to the users. Do we want the search functionality on all the pages of the website? No. We only want it to be available when we access the products page. So the when is the trigger? Remember that? Only afterward we asked for the expected behavior. Then the search module is available in the top right corner of the screen. Why? Because we need to illustrate what should happen. If I access the website and landed on the products page. The expected behavior in our case is that now I can see the search box. Okay? So we can see the search box on that page. But how do we make it work? Well, that's fairly easy. We can write another scenario as part of the acceptance criteria. So now we'll have Scenario number two with a following title. The user can search for a specific product by name, following the given when then magic formula. Here's what we've got. Remember. At this point we can only see the search box. It doesn't do anything yet. So here it goes. Given that the user has submitted specific search criteria using the search input box. When the user clicks on the search CTA call to action. Then the filtering is performed according to the specified criteria. And the search results list is displayed containing all the products matching the search criteria. One important note here, you can have multiple given prerequisites are preconditions. And you can express them by using end. For example, given that the user has submitted specific search criteria using the search input box and the search input box contains valid characters. You can also have multiple than expected behaviors, like for instance, in our previous example. Then the filtering is performed according to the specified criteria. And the search results list is displayed containing all the products matching the search criteria. But there can be only one when the trigger must be a singular expression, one single event. Also, in terms of scenarios, we need to be careful to specify all possible cases. Happy case scenarios, fail cases, and the edge case scenarios. And denoted to do that properly, we need to walk a mile in customer's shoes and always question every action and every decision. That's the only way we can maximize our chances to uncover all possible use cases. So there you go. A lot of things need to be considered when writing user stories. And it's a process that should not be taken for granted. Writing proper user stories. Once that the development team can easily understand and implement ones that are clear, concise, and with the right amount and quality information is an entire process that can either make your life easier or can cause nightmares and a lot of trouble. A couple of tips and tricks for you to consider. Start big and break them down as needed. Uses stories are meant to be refined. Don't focus on doing it all at once. Think about user flows, then create a vertical slices to support them. Meaning, use Story Mapping, right? And review them as a team. Because this creates a shared understanding. This is not a one man. Show it as a collaborative endeavor. Focus on underlying the need of the customer, not the perceives and state. Don't sweat the format. There are many valid ways to write a user story. Just figure out what works best for the team and then be consistent. User stories are the structures that start and capture the conversation around value-based feature centered on your users. And remember, you are not your user. Last but not least, invest in your stories. And most importantly, ask the who, the what, and the why. Use all of this information as your Northstar. Even though most probably you won't be able to create a perfect uses to reach and every time. But practice makes perfect. So keep up the good work. Acknowledged the importance of writing proper user stories and make your life easier in your job more enjoyable.