Hi, Philip Chesney here from AgiFall.
For today’s video, we are going to see how
to write user stories.
First, user stories are a short description
of a small piece of business functionality
that usually takes 1-3 days to complete.
In many cases, teams will break down specific
product features into more manageable, bite
sized pieces and put them onto index cards,
sticky notes or into other programs like Jira
etc.
Once we have these user stories written, they
are added to the backlog and then prioritized
as per the customers’ needs.
You will choose user stories that add the
most value to the stakeholder, end user or
customer.
Let’s see how to write user stories.
1.
Start by writing down possible stories otherwise
known as candidate stories.
We write these stories because we believe
they will be part of building a particular
feature.
Let’s imagine a feature e.g. taking a picture
on phone.
Now, some of the candidate user stories could
be: create a zoom function; add a video record
option; add filters etc.
The team then needs to give an initial estimate
on how long the stories will take.
As we start our release planning, we can then
go back and re-estimate the stories to give
more detail.
2.
Officially though, they are not user stories.
To become user stories, they need to be written
from the perspective of the customer and then
written on the cards.
Our user stories must reflect what the user
desires and the language and way he would
describe it.
You should have an idea of who your customers
are and create a list of personas.
See the video on how to use/write personas.
3.
Look at a format we can follow.
This isn’t the only format, but it’ the
one I’ll present today.
a.
As a (role/user)
b.
I want (functionality)
c.
So that (benefit)
For example: as a lover of picture taking
on my cellphone, I want to be able to zoom
in with high resolution so that I can take
great pictures of nature and animals.
One valuable thing to remember is that when
we write the stories, we need to be able to
test them, so we can know when they are finished.
This is known as the acceptance criteria.
The story is done and accepted by the customer
or it is declined.
It is only one or the other.
So, we need to write our stories so we can
test them accordingly.
Here is another example: As a project manager,
I want the website to offer a series of how-to
videos, so that when I have difficulty or
want to review something, I can easily learn
how to do it.
There are multiple ways to keep track of your
user stories.
I have added a downloadable Excel option here.
Other professionals may use Jira or other
PM tools to keep track of their user stories.
Just remember though, the best-case scenario
is if these stories can be visible.
If you have wall space, put them up on the
wall!
This helps increase collaboration, promotes
transparency, and others will know when there
are new stories up on the board.
Before we wrap up, let’s look at one more
user story to solidify the concept.
As a user, I want to be able to log into the
platform via Facebook so that I can access
my account.
Right below it, we also have our acceptance
criteria: account login can be done via Facebook
for all user accounts.
So, there you have it.
I hope that you have liked today’s tip and
will be able to put it into practice.
Feel free to leave any questions, comments,
or share how you and your team normally write
your user stories, and make sure to subscribe
to the channel and share it with your team.
