This article is part of the Effective User Stories Series.
If you’ve missed reading Part I: Why User Stories and Part II – What Are User Stories, we strongly recommend you check them out first.
In this post, we will discuss how to write effective and powerful User Stories.
Let’s deep dive into the anatomy of a user story.
Writing User Story Fundamentals
Good User Stories are answering the three fundamental questions:
- Why is it important (the problem we are solving)?
- Who is the user that will benefit from the value?
- What needs to happen from the user’s perspective?
And equally important, good User Stories MUST NOT answer the question:
- How will we do it?
User Story Template
We recommend the following template to define your User Stories:
<User Story Short Title>
<User Story Description>
<User Story Acceptance Criteria>
Let’s deep dive into each component of the template.
User Story Title
The User Story title is describing with a couple of words what is the Story about and serves as a quick reference:
Example:
User Login
User Story Description
Most Product Owners tend to believe that the best approach for writing a User Story description is by following the template:
As a [user_role],
I [want/need/can ],
so that [reason]
This is one way to do it, but it is not the best one. It is the most widely used template not because of its efficiency but because it was repeated too many times by the right people.
We’d highly recommend writing a User Story description by using the Start With The Why template:
In order to [benefit of something / why?],
As a [user, persona, role / who?],
I [want/need/can> <goal / what?].
It’s better to use the second template because its main focus is NOT on what needs to be done but on why the user needs it. This is helpful for two reasons:
- The developers don’t feel and act like coding monkeys. They have the freedom to be creative and innovative. The team is empowered to implement the Story in the best way to satisfy the customer’s needs.
- The whole team has a clear vision of the value behind the Story. This enables their agility to provide alternative solutions when needed, that no one has even thought of, to meet the customer’s needs.
User Story Acceptance Criteria
As we discussed in the previous blog post, the Acceptance Criteria form a short and clear checklist that needs to be fulfilled, so the Story can be considered “Done”.
Full User Story Example
Title: User Login
Description:
In order to use the system functionality,
As a system user,
I want to be able to log in with my credentials.
Acceptance Criteria:
- User can log in using their username and password
- On successful login, the user is redirected to their “Personal Account” page
- If the username or password is incorrect a warning message is shown
- Block the user’s account for 1 minute after 3 unsuccessful login attempts
Is the User Story meeting the Definition of Ready?
To avoid having poorly designed User Stories, we recommend you to have a Definition of Ready (DoR). This serves as a quality gate for the team to evaluate whether the Story is clear enough for them to start working on it.
You might already have a Definition of Ready (DoR) and if you are not sure if it is good enough or what exactly it should include, then follow the INVEST principle.
INVEST stands for:
- Independent – Stories are easiest to work with if they are independent. We’d like them not to overlap in concept and to be able to schedule and implement them in any order.
- Negotiable – A good Story is negotiable. It is not an explicit contract for features. A good Story captures the essence, not the details. Requirements will be co-created by the team during development.
- Valuable – A Story needs to be valuable to the customer.
- Estimable – The team should be able to provide a rough estimate (not an exact metric) about the effort needed to complete the User Story.
- Small – The User Story needs to be small enough to be completed during a Sprint or less.
- Testable – The User Story can be tested once “Done” and verify whether the user value is delivered.
Before committing to work on a Story, first go through the checklist above. If the User Story is not meeting even one of those criteria, it will not meet the DoR.
Now you’re equipped with a great approach toward defining amazing User Stories. Remember to always start with “The Why” – the problem your user needs to solve and leave the “How” open for innovation and creativity.
But who is actually “The User”?
Are all users the same?
How can we improve our User Stories to address customer’s needs even better?
We will give you answers to these questions and more practical techniques in the next article.
