So let's think about this portion of a story now that we've talked about the backbone of the user story
map, we have to talk about the body and that's what happens underneath.
Now, the body of the story that describes the details of how to make tasks happen, the body has two
elements user stories and releases now user stories.
These are the details of how the tasks are done to meet the goal.
An example would be.
Let's figure this out and your personal details.
I want so typical, your story would be as a user, I want to do something because of something.
But if I were to write this in a more simple way, let's actually bring down the font size so we have
more room.
So.
As a shopper, I want to be able to enter my name and e-mail address so that the application knows who
I am.
So that's what a user story would be.
Gives us a good insight into the type of features that we need to build for this application, but also
the reasoning behind those features.
Another one could be, as a shopper, I want to be able to enter my address so that I can get relevance
results based off of my location.
I'm not sure if this is actually going to be possible, but it's another way to think about features
in a different way instead of just saying we need to have a sign up form.
I mean, yeah, that makes sense.
But why do we need to have a sign of form to the sign up form, have different aspects to it?
Do we need to create an entire onboarding experience in order to facilitate larger experience for the
users and like finding products and etc.?
So these user stories really help to make us understand, like the different types of steps we need
to do to complete these individual tasks and the reasoning in the user motivation behind it all.
Now let's think about the second part of the body releases the releases.
They helped to describe usable and testable versions of the application that can be released.
Know it's helpful to make these as small as possible, but also as descriptive as possible.
For instance, the first release of this like application that we're building habitual could be just
a way for a user to see all the different products that are relevant to their interests, has no search.
It has no profile necessarily just yet.
But we're only thinking about the little pieces of information that we need to get started.
So if we want to move this release line up over here.
We can start breaking this into different releases, so we have our first release here, an example
for use your story for interest that we want in our first release, which I usually call the MVP release
could be I want to give a list of things I am interested in.
I'm going to save you some time and not right out of the entire year.
Sorry.
A second thing that may make it into the release.
I want to tell you my hobbies, because maybe we can pull from that type of information so that they
make it into the release.
And so we just can give them some space.
And as you can tell, we're starting to build out a release of features that we find to be the highest
priority.
So an example here would be I want to list products that I really like.
But something that may be out of scope would be something like, I want to connect a previous shopping
application to show you my purchase history.
Like I said, I'm not sure what exactly is going to be possible from an engineering standpoint, but
as you can tell, this isn't really a high priority in order for us to understand if we can serve up
relevant products to our user just yet.
You know, maybe one thing for education and onboarding, maybe there is I want to see an intro screen
that's probably needed.
I want to see how long I am in the process.
For onboarding, that could be another that we definitely need.
So this is how we start to create releases.
And like I said, these enhancements will come at a later stage.
It's not like we forget about them, but they just aren't as important to us right now.
And in this moment now, people often say, what do you do from here?
Well, I would start designing this release and then the goal would be to validate it.
It's often difficult to know for sure that the activities and tasks listed match, you know, how the
target user performs or thinks about these activities.
The closer the similarities between the activities and the tasks in the story map are to the actual
target users mental model, the more intuitive the application starts to seem.
So that's when we start to bring in things like user testing to really understand your motivations and
the reasons they want to do certain things.
We can also take this prototypes that we build based off of these features that we're building and talk
to our users about them and see if they can use them, see if they want to use them, get their feedback
on those types of things.
Now, this is what my process is like when I start a project, I also use story maps for whenever we
build larger features.
But I'm always, always thinking about ways we can implement the smallest release possible, even on
a smaller scale of enhancements.
We want to make sure that we're not committing to too much because in and of itself, these stories
are risks.
They are assumptions that we're making about the user.
And if we take on too much before we actually validate, it may all be wasted work.
And that's incredibly expensive.
So I say, get out there, try to figure out who your users are and start mapping out the different
types of features you want to build that you think you should build based off of the input from the
subject matter experts that you have in your product alignment canvas from your product team.
Go out there and don't just make assumptions, but make sure that your releases are really planned based
off of different types of feedback and different types of understanding and validation of who your users
are and what their goals are.