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: 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 approach, 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 team. You invite
the product owner or the Scrum Master and the development team because you wanted
to make sure that everybody is participating and understand what we want to build.
In terms of timing runs, depends on the project. It can take all the way from few
hours to 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 start 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 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 theme 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 recent 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 user, 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 story
map. So the structure of a story map is there from left to right is chronological,
so it shows if a user does X and then do 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 in multiple ways and sometimes more advance on the bottom and
the basic one on the top. So that's basically the basic structure of a story map,
but then you can augmented it with additional detail, for example, you can take,
you can create screenshots or you can create mockups and put on the top to
represent that these kind of functionality is shown in that mockup, so you can
relate how it's going to look like, or you can also include nonfunctional
requirements on the side, which is applicable to the whole story map or other kind
of requirements. And again, story maps are very free form structure. So these are
the core structure 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
facilities. 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 viewed 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 shows 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 are their contacts? 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 shows 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 you, in the 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 the 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 talk 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 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 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 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 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 or 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 a 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 it 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 goes 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 helps you build better software.