How to Write User Stories

Having gone through the user story mapping session, we should have a list of goals, actions, and actors.

Story template

We can use the following template to write those goals down if we’re out of ideas. The better we can describe them, the easier it will be for future readers to understand them.

As a <actor>
I want to <perform an action>
So that <I will achieve some goal>

This is the feature description. Its purpose is to remind everyone in the team of the why behind the user stories that follow. The description usually provides reason and context so that we don’t have to be too verbose in the user stories.

After the feature description is in place and provides its context, we can write the user stories. They’re nothing more than descriptions of what the user’s journey will look like in the context of our application. We can take the rough ideas we’ve sketched out and put them in context. We can imagine and vocalize the user’s journey.

An example

Here’s an example:

Let’s say I’m on the homepage. When I click the login button, I should see the login form.

And here’s another one:

Given I’ve just logged in, and I click on a concert banner, I should see the concert details page.

There’s a template we can use for user stories as well:

Given <context or precondition>
When <action I want to perform>
Then <result I expect to see>

Using this process whenever we plan a new feature or set of features will pay off big time. Let’s explore why.

The outcome of stories

Two things have happened after gathering all our stories and going through all the details with the stakeholder.

1. We’ve aligned our expectations.
2. We’ve written our first set of tests.

Aligning expectations

Aligning expectations with the stakeholder is important because it gives us context for how things fit together to form a complete product. It also helps the stakeholder prioritize actions based on their value to the user.

While spending time writing code is fun, sadly, the person paying us to do it sees it as an expense . So, knowing where the money goes ahead of time is helpful for the stakeholder.

In an ideal world, we’d have a high-level conversation with the stakeholder about the future when we’re done building the product, how many users will use it, and how the bank accounts will start growing.

But, that’s not how it happens.

In reality, the building process takes a very, very long time. The more complex the project, the longer it will take. Then, getting the word out and convincing users to buy will be a significant effort for the stakeholder (and their marketing team).

Leaning on the pessimistic side of the story will help us keep things real and in focus. Being overly optimistic will only crush our expectations.

The tests

Let’s now talk about the second thing, that is, the tests.

The stories that we’ve written are our tests. Yes—that’s the actual code we put in our application.

The tool that understands this code (the stories) is called Cucumber.

Cucumber

Here’s a Cucumber story: