In this lesson, we are going to learn about how do you generate user stories on an Agile project, or where do the user stories come from? We're going to learn about a couple of techniques that can help you generate user stories for your product backlog. So we're going to talk about two matters: the first one is User Story Writing Workshop and the other one is called User Story Mapping. Let's talk about the first one. So the User Story Writing Workshop is the simpler of the two approaches, it's very straightforward. So in terms of logistics, the goal of a User Story Writing Workshop is to write as many stories as you can for the selected theme. You invite the product owner or the Scrum Master and the development team because you want to make sure that everybody is participating and understands what we want to build. In terms of timing, it depends on the project. It can take all the way from a few hours to a few days. In terms of agenda or exactly what happens in this User Story Workshop, generally the first step is to identify who are the users of your application? So you identify a job seeker or administrator or these are the people who will be using our system, and then you do some analysis on these users. How tech savvy are they? Sometimes you even create personas that define these user roles and you give them a name. Once you understand your users, then everybody in the room kind of starts writing stories as to what functionality we want to provide to them around the selected theme, and you can use different approaches. You can go from top down, so which means you're going to start from "Ok, here is the major functionality we want and then we start splitting or writing the smaller stories for them and then go down further." Or you can do bottom up where you are just writing the low-level stories, and then once everybody is done writing stories, you can group them into themes or epics and then you can go from there. Or you can just keep it free-form, you can write an epic or you can write gradual stories. You don't worry about what level you're writing the story, but you just start writing and then at some point, you put them together and you organize them so that it flows well. So, once you're done with this whole exercise, after that you create the product backlog with all of these stories. And here are some of the characteristics of a good product backlog. You want your stories to be detailed appropriately, something that will be done in the near future, you want more detail, but something that is not going to be done in the near future, then you don't need that much detail. You want your product backlog to be emergent, which means it's always evolving in terms of user needs, in terms of the details, should be estimated, so you want all your stories to be estimated. It allows you to predict or plan your releases and then you want your backlog to be prioritized. So if anytime you're going for a screen planning or any of those activities where you want to decide what to do next, if your backlog is prioritized you can pick the top item to work on. So that's the story workshop. Now let's talk about the story mapping, which is the better way in my opinion to understand user needs. So story mapping was popularized by Jeff Patton, and it's a technique primarily to discover user needs. What are the needs of the user? It really helps you discover those needs. But in addition, it helps you organize and prioritize your story backlogs, helps you understand and communicate user needs, and it also helps you plan releases. So let's see how it does that and what are the steps to create a story map. So, the structure of a story map is that from left to right is chronological, so it shows if a user does X and then does Y, we'll put the first item on the left and then what happens after second and the third and so on. So from left to right shows the time, and from top to bottom it shows the priority. So a story on the top is higher priority than the stories on the bottom. The orange stickies represent the user activities. So those are the things that are big things that a user wants to achieve from the system in one sitting, so user activities. And then the next, the blue sticky, shows the steps, the basic steps that the user is going to do to achieve those activities that are represented in the orange. So the first blue stickies represent the activity for the first orange sticky on the top and then all the yellow ones are the user tasks and they are the variations. So to do the blue sticky, you can do it in multiple ways and sometimes more advanced on the bottom and the basic ones on the top. So that's the basic structure of a story map, but then you can augment it with additional details, for example, you can create screenshots or you can create mockups and put it on the top to represent that these kinds of functionality is shown in that mockup, so you can relate how it's going to look like, or you can also include non-functional requirements on the side, which is applicable to the whole story map or other kinds of requirements. And again, story maps are a very free-form structure. So these are the core structures but you can use it or you can use your own annotation and your own understanding or own custom rules to augment the story map with additional details. Here's one example of a story map. So in this case, let's take a look at the activities that the user is doing is "initiating session", "monitoring a facility", "adding notes to the log" and "ending a session". So this is a story map for a software for monitoring the security monitoring. So, let's take a look at "monitoring a facility". So here, a user is going to view the motion sensor data, then he's going to see the feed from the video, view the infrared sensor and so on. And then let's look at some of the variations on one of the columns. So under the "view motion sensor data", the user can first, the basic things will be "view the overview", and then he can "view the alerts per zone". So those are the advanced story that he may want to see further. So the stories on the vertical line show all the way from basic to the advanced or higher priority to the lower priority. The line, that horizontal line, basically divides the first release from the second release. So, I think hopefully this gives you a good idea of what a story map looks like. Now let's talk about what are the steps of creating a story map. So the first thing you want to do is to really understand the problem, you want to understand the users and you also want to understand what is the benefit of the software that we are building to the organization? And when you are understanding the users, sometimes you also create the personas. So you gain a little bit better understanding of the user, what is their context? What is their background? So once you have a basic idea about the problem, you start with outlining the activities that a user will do in the system. So, you can ask the people in the room, you can ask what do people do with the system? And then as they are seeing things, you start writing those in the stickies and you put it on the board. So these blue stickies right now show what are the main activities that a user will do in the system. Once you have these activities, then you ask for each of these activities, what are the steps that a user is going to take to do those activities? And so those big pink stickies are basically showing, the first two pink stickies are showing what this user will do to achieve the first blue activity and so on. And then, in step three, you are adding all these variations, so you say, "Ok, the happy path is covered now, let's talk about how else or what else can you do." And when the user is saying, "I'd do this and then I do this and then I do this", you end up stagnant horizontally, but if the user is saying, "I can do this or I can filter by first name or I can filter by last name or I can filter by age" or whatever, then those are the variations or the alternatives that a user can do. So we are going to stack them horizontally because those are the same thing searching for someone but different ways of searching. So, horizontal is the chronological order, so "AND Then", and then "Or" is the vertical which are the variations. And then again in step three, you can capture the details also. So for example, for a given task, if there are a lot of details that we want to capture, we create all these stickies and stick it under the main task. Then what you want to do is once you have the first version done, then you want to keep talking aloud the same story map again and again and see if you missed any detail, test for completeness and then don't worry about like if something will be done or not done, because everything will be prioritized and sliced out. So just let your thoughts out and put what you would like to see in the product in the story map. Look for exceptions, consider other users. So maybe you ran through the story map with one user, now you can look at another secondary persona and see what additional thing they would like to have. And then you should also involve other stakeholders and say "Ok, we created this story map. What else is missing?" So, during this explore phase, you just keep on expanding and adding more and more to your story map. And then once you have the story map ready, you're ready to work on it, so next thing you want to do is slice out why we'll release it. So you say, "what will be the first meaningful release?" And so you select the stories that will be the first meaningful ones and then you separate them from the other stories. Now when you're selecting the release, focus on the outcome. Anything that is not contributing to the outcome, remove those stories from that release. And then once you have identified the release, write down what is the outcome and what's the impact of that release and what is the success criteria for that release. So these are the four steps that can help you, that you can follow to create a story map. Now let's talk about what are the benefits of creating a story map? As we talked about, the main thing is that it helps discover user needs, and especially how to discover missing pieces. So because when you talk aloud again and again you say, oh, this is the step that a user might take, so it helps you discover those missing pieces. Then it also helps you understand and communicate user needs. So let's say you are meeting with some executive, then you can just use this story map to communicate what you're building and maybe you can stay at just the activity level and you don't have to go to the detail level. So, a story map also allows you to communicate at different levels based on your audience. And since it is a user-focused document or artifact, it helps you tell a story in a user language. And so people do like that concept where you are telling a story of what you're building from a user perspective. Then it also helps with the planning like we just talked about in step four. It can help you create or plan your release. And because you're creating valuable slices of functionality, it's a much better way of selecting stories other than from a list of stories from a backlog. And it also provides that context, let's say you pick something from the story map, it provides the context as to what is before and after, needs to happen for that release. And of course, it helps you organize and prioritize your story backlog because all of these stories then finally go into the story backlog. So you can help, based on your release, based on what you select, you can organize and prioritize your story backlog. Now since this activity is done with everybody in the team, then it fosters the co-ownership in the team and everybody owns the product that we are building and then it's very flexible because, like I mentioned, you can add your own annotations, you can add your own details to the story map to make something of your own or add things that help you build better software.
