The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kingsman Walsh.
Hi everybody, and welcome back to the Better Business Analysis
podcast with Benjamin Walsh. And I apologize for my voice.
I have been down with COVID for the last week, but we're going
to continue on our BA Byte series.
And today we are going to follow through 10 top tips for writing
awesome user stories. So if you follow me on LinkedIn
or you are, you know, one of my, I guess, friends on there, you
will see that the Better Business Analysis Institute
published a white paper called User Stories 2.0.
And we're going to get to that in #10 but we're going to count
down 10 top tips. These are really important.
I dip into the subject a lot and I think any BA, doesn't matter
if you're senior or junior or getting started, will get value
from from today's session around writing effective user stories,
which is critical. And you, it's critical because
it ensures that the delivery team, the development team, are
building staff, features, deliverables, approving
processes that actually deliver real value.
And real value is not just a buzzword, it actually means
something the customer cares about.
So we're going to walk through 10 top tips for writing awesome
user stories with examples focusing on clarity, actionable
details and connecting user stories to the broader business
process. We'll also introduce the User
Stories 2.0 concept which the Institute has published, and I'd
love to get your feedback on that.
So let's dive in with number one.
Number one is keep the story focused on user value or
customer value. Ensure that the story is centred
on the user's needs and the value they will receive.
They receive a value item. OK, User stories should not be
about technical tasks. OK, there's a lot of people out
there who write user stories to talk about what they're going to
do. No, it's not about technical
tasks, but about delivering things, features, if you like,
that solve user problems or provide benefits.
I'll give you an example. As a customer, I want to see
recommended products based on my previous purchases so that I can
quickly find items that match my preferences.
A lot of ecommerce sites to this, OK.
And of course, there's acceptance criteria under that
you can put in the description or the acceptance criteria
field, which will be recommendations should be
personalized based on my previous purchases within the
last six months to introducing a bit of a business rule.
There some constraints around the user story.
The recommended product should appear on the homepage when the
user logs in. So this is description of the
user story. This is the comic book.
So when you write your user story, one of the best ways to
make sure you've covered it off is draw a little comic book
strip. OK, if you're from the world of
user stories and not use cases and traditional business
analysis, visualize how you think this will become true.
And some of those additional points will become description
acceptance criteria in your user story.
It's #1 keep the story focused on user value #2 is be specific
with the desired outcome. Clearly define the outcome or
benefit the users should be experiencing.
Vague goals lead to misunderstanding about what
should be built. OK, and this really focuses on
the so that I aspect of the user story.
So here we go. As a project manager, I want to
receive e-mail alerts when tasks are overdue so that I can follow
up with team members to avoid project delays.
Lots of people could have written so that I receive an
alert or so I am notified. They just rewrite that I want to
and the so that I This is an easy problem.
Don't do it. It is my advice if you catch
yourself doing it, and sometimes you do it because you're rapidly
writing these things, go back and change them.
OK, So you need to think about why.
Why is that feature? Why is that function important
to the person? And it's usually not a technical
reason. And so in this case, it was
actually so they could follow up because it's really important.
At least there's so many other aspects of product management
and why you create value and by the alternatives.
And when things are tough and you need to prioritize, then the
why is all that matters. OK.
And so again, you can have acceptance criteria.
Alerts must be sent when a task is more than 24 hours old.
And the task alert should not include or should include,
sorry, the task name, assignee, due date, and so forth.
So that's really around #2 which is be specific with the desired
outcome #3 is really important. And I'm going to talk about
breaking down in more detail here.
Breakdown user stories or stories, the general term, into
small manageable chunks. That's the whole point of the
agile cycle and sprints. So large stories, epics are hard
to implement in a single Sprint. That's the purpose of breaking
them down. So there's two reasons.
One is the side from the delivery side that they're too
big, but they're also a great start, as I said, to, to link to
traditional business analysis and real business analysis, if
you like, of capturing high level requirements first.
But you do need to break them down into smaller, more
manageable user stories that can be completed within a Sprint.
And so you could break these down again into child user
stories. So you might and and and a child
user story might supersede the the previous user stories.
So you can either have children or you can archive and just have
smaller more user stories if you like.
So I'll give you an example for a large area, like, I don't
know, managing my orders, you could break that down into
smaller stories. As a customer, I want to view my
order history. So it's a it's a sub function of
or managing my order. OK, so that I can track past
purchases or you might have as a customer, I want to update my
shipping address before order is shipped out.
So these are all sub features. And again, you can visualize
this if you draw up what you think is a conceptual version of
an order strip screen, this really helps.
This is not cheating. Some people think you're
bringing up pen and paper. It's like, oh, you're starting
to develop, you're starting to design well, you'll know you're
just conceptually thinking about it.
There's there's, you should be doing this as a VA draw a
picture and go, oh, what's on an order screen or, or look at your
order screen. So you're like, well, they want
to be able to be able to view their order history, don't they?
And update their shipping address.
And so this is all part of it. This is all passive, the
analysis and design in the sense of business analysis.
So you do that and you go, OK, well, we've got this, this
massive epic around managing my order.
We're going to manage my order screen, but actually now we've
got some sub components if you like.
They will be components by the developer's side.
And from your point of view, they're just, they're functions
that need to be reformed. OK, the user stories and you can
write them down even further. So for example, you've got to a
point where you're like view my order history and the order
history screen was massive. That's where you could say,
look, I really want them to not just view the order history, I
want them to be able to view specific details of their
previous orders, right? So like go back in time, see
what was delivered, when it was delivered and all the rest of
it. So that could be another user
story. So you, you get into the order
history and the, it's come from the product owner.
They've spoken to customers and they want to track past
purchases and you find out it's a bit more than you thought it
was going to be. It wasn't just the name of the
order and the item. It was like when it was
delivered and submitted data around the order.
So that's a child user story of that particular user story.
Or you could just create a new one, add this backlog and say,
look, we're going to implement this version of it.
My order history as this user story 1st and then it's going to
be my order history details, view or advance details or track
that on the backlog. And that's not going to be done
this spring. That's what we mean by breaking
this down. They all contribute to the epic
which was managed my order. Does that make sense?
But there's a relationship between view my order history
and this new view my order history, you know, details and
that there could be linked as a child user story or just Simply
put on the backlog at the kind of same level.
I like to use child user stories and that's why I would break it
down, OK, But it wouldn't be implemented in that Sprint.
It doesn't mean that the children are all done in the
same Sprint. OK, let's move on to #4 add
clear exceptions criteria. So just to be clear about
acceptance criteria. Acceptance criteria define how
the story will be validated. OK.
And this helps the developers, the testers and stakeholders
know when the user story is done.
So they the the definition of done.
How do they not? And how do they know it's
working as expected? So the acceptance criteria is
being is not a, well, by the way, defined area.
And it's something that I'm quite interested in having
wrapping some guidance around, but it's being increasingly used
to fill the gap of, say, documents that have business
rules in them. So I'll give you an example.
So as a user, I want to reset my password via e-mail.
OK, It's quite interesting. It's got via e-mail.
She's now specifying with what channel, with what.
OK, so we'll come back to that so that I can regain access to
my account if I forget my password.
Very standard user story. It's one of these user stories
that you sometimes forget to Chuck into your app because you
just assume the developer's gonna, like, do all this.
And I've done that before. And the acceptance criteria
under this user story is that the user story can request,
sorry, the user can request a password reset by entering your
e-mail. OK, that's different.
It's more descriptive. It's saying that they have to
enter the e-mail. So that that if you like, you
could break this user story down into further user stories around
having a field or an area where a user can type their e-mail
address, a valid e-mail address. Can you see, can you, can you
see how you could break this down into other user stories?
But in this case, the acceptance criteria is enough for the
developer to visualize what they are going to build and they've
recognized as patterns. So you I would say there would
be less value in writing another user story or child user stories
here. But the first acceptance
criteria is around by resetting by entering their e-mail.
And the second one is a reset link is synced within 5 minutes
of the request. OK, you set your e-mail address,
you click reset password and then within 5 minutes the
request should be sent back. And there's some importance
about that. I mean, you could say instantly.
And then that can involve huge amounts of tests.
I happen to know because I've got a bit of a development
background, that it will be queued this request.
And it might not be possible if everyone's resetting their
password. It's not really a priority job.
So 5 minutes is pretty standard, or I don't actually say a couple
of minutes these days. People would expect an e-mail
reset or they'll go back and reset it again.
And then the last acceptance criteria #3 is the reset link
will expire after 24 hours. So it's around security and
making sure that it's not forever or hackers can't gain
access to it. So that all what I'd call
business rules that you're applying in the acceptance
criteria and that all have to be true.
So that allows the user story. Ultimately the resetting happens
and you've specified some rules around how it has to happen. 95
is so important. User stories.
You get so wrapped up in your epochs, user stories, product
features, all the rest of it. Don't forget about non
functional requirements. Most projects that encounter big
disasters when they go live is because the BA and the team and
the architect haven't thought about non functional
requirements or done a good enough job.
They are overlooked. They are critical.
They are critical not just for your reputation, but for user
satisfaction. So we just talked about before
around there was this resetting option, What would happen if we
hadn't specified a time or worried about performance of
this particular resetting of password or even security?
OK, so we for example, when we reset the password, we sent the
old password in the URL. That would be a security
problem, a non functional requirement.
We should have to to make sure that doesn't happen.
And that would cause a security risk.
And actually people would be able to just instead of
resetting the like they can just take the old password, enter and
get into your account. So you need to think about
things from a non functional site and there's usually
templates. I've got lots of good content
about non functional so I'm not going to go on about the point,
but I'll give you an example here.
As a user, I want the system to respond quickly when searching
for products so that I can find items without delays and this
will stop me from going to other websites.
And so the exceptions criteria could be search results must
repeat appear within 2 seconds of 90% of queries.
The system should handle up to 10,000 concurrent search
requests. So these are all non functionals
around the interaction with the system in order for the features
functions to operate correctly, securely, you know, performance,
a scalable, a usable and and this includes things like
content and web standards as well.
So they're all come under non functional requirements.
So do not forget about non functional requirements.
Number six is and I actually had this conversation with someone a
couple of weeks ago. Focus on one persona per story.
Don't have a group of personas. Think about the individual
persona, individual user that you're focusing on.
User story should cater to a specific type of user or
persona. Trying to address multiple
personas and a story creates confusion and so that I it's
really talking about the individual persona.
So as a System Administrator, I want to manage commissions and
the control panel so that I can control access to different
parts of the system. And then an, except described
here, you might say something around admins can view a list of
items, they can grant or revoke access to specific modules.
Now that's around the system user System Administrator.
And that's a good example because it's around the people
that you sometimes forget about, especially when you're building
a system that you think, oh, we haven't built an area where the
System Administrator can actually control permissions.
We've just got a user who has a credential, OK, and just gets
allocated or wrong, but someone has to manage that.
So that's thinking about the individuals in the life cycle,
your stakeholders that are managing the system as well as
interacting with it. OK.
They all are important and we need to think about them as
individual personas. So yes, and as, as a it should
be, it should be unique there. And sometimes just as a top tip,
sometimes that can be a bit of a reply.
So early day business analysis and system design, you would do
like a sequence diagram, for example, sometimes or you would
do a use case diagram. And so think about a baton
approach. And what I mean by that is,
look, as a user, I want to be able to view a list of products
on the site so I can browse and decide which product I want to
purchase. And then so I've I'm doing that
now, what is the response? Who needs to?
Does anyone need to do that? Does the system need to do
something at that point? As a system, I want to respond
to searches for products within a timely meeting.
So the better meaning that I've done my thing, now I want the
system to do something. And if you think about it that
way, again, like a comic book, but with all the characters,
including the system as a character, you won't miss all
the user stories #7 make the user story testable.
And so we do that by doing great acceptance criteria, but we also
need to write a user story in a way that testers can validate
whether or not it works as expected.
So an example might be as a subscriber, I want to be able to
cancel my subscription from again, where?
From the account setting page so that I can stop being billed if
I no longer need the service. And then in the acceptance
criteria you might have, the user can navigate to the account
settings and see a Cancel subscription button.
Clicking the button triggers a confirmation response
calculation is processed and the user is notified by e-mail.
That completes the whole actual comic book, the story side of
the user story. They need to be testable, so
make sure that you're writing something that can actually be
tested. If it's not, then you may need
to reword your user story. And they're not all.
For example, numbers or counts could just be binary.
Does it work? Does it #8 is prioritize just
user stories by business value, not by development preference?
Not by what you think is the most important, but what the
user, the customer, the business thinks is the most important.
This ensures that the team is always working on the highest
impact items and features. So for example, as a customer, I
want to be able to track my order in real time so that I
know exactly when it will be delivered.
Now that's an example there where a user wants to know when
they want to track my order. Now let's say there's another
user story which is as a user, I want to be able to view where my
order is at, OK, so that I know when it will be delivered or I
get some idea about when it's going to be delivered.
So the fact that we have two user stories, one which is just
a roundabout to track my order bit more light and the other
ones around tracking in real time, which might be a should
have requirement. The business value might be just
to implement the tracking order first and then you will do the
real time tracking and a next Sprint if it's deemed highest
value. So you need to prioritize these
things. I would suggest that a trick to
fight to even realizing whether or not a user story is the most
valuable is that it allows the user to complete their journey,
their job to be done, so they're able to complete their full
cycle. So you should focus on them
being able to perform a step. OK, just yes or no?
Can they complete that step tracking their order or viewing
the order or checking out before you start to work on user
stories which aren't MVP for And what that means is before you
start adding additional features to other areas #9 is is never
done well here. And that is considered
dependencies between stories. Sometimes 1 user story cannot be
fully implemented without completing another.
OK, like I said, there might be a user journey.
So that's literally the the journey of the customer to get
from A to B. That's important.
Your storyboard should show that.
But also in delivery there might be some dependencies that ensure
smooth delivery. So for example, they say as a
customer, I want to pay using PayPal so that I can complete my
purchase using my preferred payment method.
That's a pretty common user story here.
And there will be some acceptance criteria that go
under that. But what we might realize is
that that's someone's working on that.
They're building a screen, they've got the PayPal logo,
they've like designed it really nicely.
They've given the user option, but there was no point in doing
that user story because I haven't completed as a system.
I want to be able to integrate with PayPal to provide PayPal
payments. So the Paymal integration must
be completed before implementing this story.
So you don't just focus, you do focus on the user value from the
storyboard point of view and what's the sequence.
But ultimately, you also need the development team to think
about what user stories need to be done and what sequence.
So for example, you can't offer pay, pay by power Pal to a
customer, which is high value if you haven't done PayPal
integration. So if there are sequences that
you just need to focus on, and so that's using dependencies
prerequisites, that would be fantastic.
And you can do that in tools like Jira, Jira and DevOps.
And #10 #10 is to adopt User Stories 2.0 to include triggers
and HDS. So to address gaps in
traditional user stories, you can adopt User Stories 2.0,
which adds 2 critical components with User stories 2.0.
What we have introduced here at the Better Business Analysis
Institute is both with trigger, OK, So that allows us to know
what entity are we affecting. This could ultimately end up
being a feature in your development.
So it's an output, a page and area.
So that is, but entity is a really good way of looking at
it. So it's like with car or wheel,
OK, a conceptual entity that you may have drawn up and we
introduce a win, a trigger, a condition.
So that allows us to talk about timing and what needs to be
true. Now this won't necessarily
replace all the business rules that you have in your acceptance
criteria, but it will give you the main reason for why and
when. And with this user story
functions around. So this is the format that we
use as a persona. I want to right perform function
desired feature whatever it is so that user value goal when
trigger condition with entity being affected.
So let's work through a really good example here.
As a customer, I want to manage my e-mail subscriptions so that
I can choose which e-mail I receive when my account is
activated OK and managed with the account setting page.
So you've, if you're ABA working on detailed user stories, you
should be in the development team.
They're talking about how they're going to design it.
And you already know conceptually there might be an
e-mail settings page. You should have drawn that up
probably conceptually and you're thinking about it.
You say, well, I want them to manage the subscriptions in this
area. So why don't you be more
explicit when you're in the detailed planning phase, you're
in the Sprint and you talk about, well, where, where do you
want this to happen? So that means the developer now
knows, and you may have drawn a picture of this, that that's
where this function should take place.
So they're not building a whole other area or they're not
guessing. So you're being really explicit.
You're, you've visualized that this would be a setting in the
account setting area, OK, around managing your e-mail
subscriptions. So that makes things really
explicit. So with user storage 2.0, you're
adding the when and you're adding the with.
And in this case, when was just the fact that you had an account
OK? It wouldn't be for customers who
weren't logged in or for customers who hadn't signed up
yet. So it was when they had an
active account. So that again, talks about
security gives quite a lot around the both the state of the
account. And of course, it might just be
any time they want to do it. And whenever I choose to update
my subscriptions and the worth of game talks links it back to
the architecture, to the actual reality of the fact there's a
component which needs to be built, which is your account
settings area. So have a read of the white
paper around User Stories 2.0. It isn't perfect, but what it
allows us to do is bring in some of the things we lost from use
cases which aren't used that often and business rules and
process and starts to really allow you to incorporate all the
thinking that you have done as a BA into the user story.
So it doesn't just get lost. So the other thing, of course,
is adding visuals to this and pointing to this is really helps
linking back to mock ups and a process diagram around when,
when do you allow them to do this?
So this feature, for example, which is around being update
your subscription preferences, your emails subscription can
happen kind of whenever throughout your kind of managing
account, your account life cycle and other examples.
There will be specific time periods when things happen like,
you know, the 30th of every month, send an e-mail to
someone. OK, so you can see the timing
and this so that will link to your process diagram and to your
mock ups. And it means that your user
stories are full and complete. So there are 10 top tips to make
your user stories awesome. I hope you got value.
Apologize for my voice today and I'll see you next week.