User Story in Agile

A User Story is a short description of something that a user will do when they use your product (website, application software). So a User Story is all about Who, What, and Why of a goal or outcome that the user wants to achieve.

It's the smallest piece of work that gives value back to the user. A User Story is written form the point of view of the end user. Let's have an example of how a user story is typically written:

"As a [persona type], I want to [action] so that [benefit]".

So a User Story consist 3 main components:

• User (Who is allowed to do something)

• Goal (What the user wants to do)

• Value (Why it is critical for the user)

Example:

Let's imagine your team is planning to develop an application for web shopping, and your work as an analyst is to write down in an efficient way the requirements of the customer.

The requirement that your customer has provide to you is "User should be able to save his delivery address, so on user doesn't need to input this kind of information, every time he makes an order"

As an analyst, you have the above requirement and you want to "rephrase" it so on to deliver value, and you come with this outcome:

As a shopper (user)

I want to save my delivery address (action)

So that I don't have to input in next time (benefit)

The above way gives an answer to the followings:

Who: shopper

What: save delivery address

Why: save time during checkout

Acceptance Criteria

Reasonably you have the question, "OK, User Story is all about rephrasing a requirement, but where is the added value, "how" is it going to help the team?"

And you are right, the "how" is not defined to a user story, and here comes the Acceptance Criteria, we need them to clarify the desired outcome, typically we describe Acceptance Criteria as a scenario (Given/When/Then), let's have a look at the following template:

Given: precondition, prerequisites

When: the event that triggers the user story

Then: the final outcome of the user story

As you see for each Acceptance Criteria in some cases it is possible to be number of "givens", "whens", "thens", and be more than one Acceptance Criteria per User Story, but no worries, if it gets too complicated, you can simply break down your story into smaller ones.

Let's have a complete example:

User Story:

As a shopper

I want to save my delivery address

So that I don't have to input in next time

Acceptance Criteria:

Given I am on the checkout section

When I input my delivery address

Then the system should give me the option to save my address for next purchases

INVEST criteria

I believe now, that it is more clear to you, which is the added value of the user stories for the team. But now, you are confused how to clarify if a User Story with its' Acceptance Criteria are in a good shape, for this reason we use INVEST criteria, It is an acronym used to remember 6 important qualities of good User Stories. Let's seek it out:

Independent

Each User Story should be independent on its own. Having stories depending on each other, when you can only implement them in a sequence causes a waterfall.

Negotiate

User stories define "who", "what" and "why", but not "how". In other words, a story identifies a problem to be solved but not a solution, so there might be numerous way to approach this story and its scope is negotiable.

Valuable/Vertical

Valuable is straightforward: everything that the team invests its time into must deliver value to the business (by delivering value to the customer).

"Vertical" means that the stories should be sliced "vertically" - cutting through "layers" of the system (backend, frontend, database etc.). If you break your stories down into "update backend for feature X", you will be likely to spread implementation of the stories over time (working on backend first, then on frontend - for a number of stories at a time) and will eventually end up with waterfall.

Estimable

Each story's scope should be clearly defined so that the team can estimate it. Even if you don't estimate your work, having a clear scope is important

Small/Sized appropriately

While it's impossible to define what exactly "small" is (as all the products and teams are different), try to make your stories as small as you possibly can. The larger your stories are, the more likely you are to end up with waterfall processes.

Testable

Before the implementation starts, you need to understand how you are going to test the story. This means you need to have Acceptance Criteria in mind and it is strongly recommended to plan the testing before development.

Bottom line

Till now we have described what is a User Story and how to approach it, the added value is that we can use them to prioritize our product backlog using User Story Mapping and we have Acceptance Criteria to prepare the test phase.