If you’re developing a digital product, then your number one concern is building something that works for the people who will use it.
When I work with entrepreneurs to help build their MPVs, they often find User Stories a weird concept. And it can be difficult to see how they fit into the project.
So, today I’m going to give you all the basics of what a user story is, what are their benefits, and most importantly, how to write them.
Enough waffle, here is what you came for…
What is a user story?
A user story is a human-readable description of how a feature in your app should work from the perspective of one of your user profiles. They are written in concise plain language sentences that can fit on an index card or post-it note. User stories are a key part of an agile software development process.
From an entrepreneur’s perspective, user stories can be a powerful way to capture user feedback, and to communicate to your product team what your app needs to do. They can make life a lot easier if you’re looking to collaborate with a digital product agency to help build your MPV – or gather estimates from developers.
What are the benefits of user stories?
User stories provide lots of other key benefits which include:
- They keep the focus on the user.
- Capturing and prioritizing requirements is more efficient.
- Easily understood by the whole team, thanks to their simple non-technical format.
- They help to avoid introducing complex detail too early.
- Versatile enough to be used for features both big and small.
- Give your team flexibility to adjust the priority in the backlog.
- Provide visibility and enable the team to work together with less friction.
- Prompt the team to think critically to find creative solutions to meet user’s needs.
- They leave the technical implementation details up to the development team.
- They create momentum – as each story is completed the team can see the progress being made which spurs them onwards.
Phew! That’s a lot of benefits.
If we’ve managed to interest you with the numerous benefits, you’re probably wondering – who writes the user stories?
Who writes user stories?
Anyone in the agile product team can write user stories, as their plain language format requires no technical knowledge to write – making them accessible to everyone. That being said, in some Agile teams the Product Owner is responsible for writing, organising and adding them to the product backlog.
When you are starting out on your digital product journey, and everything is in your head, the best person to write user stories is you! Going through the process early will help make things clearer both for yourself and the team you end up working with.
This brings us on to the next question…
When do you write user stories?
Most of the user stories will be written at the start of a project, but more can be added to the product backlog at any time. This is a core feature of agile projects, where functionality and business logic can change depending on feedback or information that is gained along the way.
As background on the way we work at Full Revolution. We start projects with a discovery phase that includes writing a product requirements document. The product requirements document contains all the user stories for the core features, along with other essential information for the project. This document helps us with getting initial stakeholder agreement and onboarding new team members as the project requires.
Now that we’ve covered the ‘what’, ‘who’, and ‘when’ of user stories; it’s time for the ‘how’.
How do you write a user story?
Creating user stories is straightforward, so long as you know how to format them, and can clearly describe what your user wants to do.
While user stories are written in plain language, formatting them can be tricky to grasp at first. One of the most common being the Connextra template, which looks like this:
As a <role> I can <capability>, so that <receive benefit>
The beauty of this template is that it’s a guideline and can be changed to suit your needs. For this reason, the ‘so that’ part of the story can be considered optional.
Here are some examples using the Connextra template:
Example 1:
As a [Customer] I can [see the items in my cart], so that [I know what products I am buying]
Example 2:
As a [Student] I can [book a tutorial], so that [I can find an available time that is convenient for both my Tutor and I]
Example 3:
As a [Marketing Manager] I can [see the number of new customers gained and what channels they came from, over the last 30 days], so that [I can show my boss which of our initiatives has had an impact]
These examples clearly show who the intended user of the feature is, the goal they want to achieve, and what benefit it will provide them.
Simple right? Well, that’s the idea at least.
But as you can see from the examples, these only cover one function of a feature. Most features have many functions. So, in our shopping cart example we may also need to add and remove items.
If you’re working on an ecommerce product, then you’ll more than likely need features that include checkout, payment processing, order management, user notifications, and stock control. To name but a few.
Very quickly you can end up with a lot of user stories, and without a system for managing them it can become a disorganised mess. One way to help tame this mess is with an ‘Epic’.
In agile software development processes, an Epic is a group of stories that make up a feature or groups of features that are too large to complete in one sprint.
For our e-commerce product, we may have an Epic where the user story is:
As a [Customer], When [I find a product I like], Then [I want to be able to buy it]
Then all our related stories can sit under this one Epic story.
Going beyond user’s desired results with Gherkin
While user stories written like our examples above are great. Sometimes you need to make things a little more specific, with regards to how the feature should work for a user. That’s why at Full Revolution we often write out our user stories in a format known as Gherkin syntax.
The advantage of Gherkin is that it goes a step beyond most user story formats by describing user behaviour – which makes acceptance criteria easier to identify.
This may sound a bit technical, but all this basically means is, our stories use the keywords: `Given`, `When`, or `Then`.
Here’s an example user story template using Gherkin:
As <user profile>, Given <criteria>, When <action taken>, Then <desired outcome>
So, here are what our previous examples could look like written using Gherkin syntax:
Example 1:
As a [Customer],
Given [I have added items in my cart],
When [I click the view cart button],
Then [I should be able to see my items]
Example 2:
As a [Student]
Given [I am logged into my account],
When [I go to the ‘book tutorial’ screen],
Then [I should be able to choose an available time slot]
As you can see, this format is still easy to read but can be a bit trickier to write. For this reason, it’s a good idea to start with the less complicated Connextra template. Then use this format later when needed.
If you want to know more about writing user stories with Gherkin, we have a more in-depth guide here.
Now you know how to write them, you’re probably going to want to know what makes a good user story.
What makes a good user story?
To write a good user story you need to consider four things:
- Who is your user?
- What do they want to do?
- How does your product enable them to do it?
- And finally, how will you know when it’s been done?
Let’s break these down…
Define your end user
Who will be using your product? If you have multiple end users, you may need to make more than one story. A handy way to keep the user in mind is to create a profile for them, by giving them a name, a photo, and a goal they want to achieve.
For example, if you are working on a content sharing product, you may have user profiles for: subscribers, authors, and editors. Each of these user profiles will have some different requirements, so you would need to accommodate these.
Example:
As an [Author]
Specify what your end user wants
Clearly describe what your user wants to achieve by using this feature. You can refer to the goal from the user persona to inform this.
Example:
As an [Author], I can [write my own articles on the platform]
Describe the benefit of your product
What benefit will the user gain from using your product?
Example:
As an [Author], I can [write my own articles on the platform], so that [I can avoid sending Word documents back and forth to my editor]
Add acceptance criteria (a.k.a. Your definition of done)
Acceptance criteria is about defining how you will know when a user story is done or not. Each user story should have at least one acceptance criteria, but try not to add too many, and remember to write from the user’s perspective.
As an [Author], I can [write my own articles on the platform], so that [I can avoid sending Word documents back and forth to my editor]
● Writing + editing user interface
● Article saving & updating
Note: In our Gherkin syntax examples, the story is the acceptance criteria. Which makes it easy for the tester to follow the steps of the story, and if they can complete the steps, then the story is done! (Good job team)
The process of user story creation can be broken down into “The 3 Cs”.
What are the 3 Cs of user story writing?
The “Three Cs” is a formula for user story creation, which consists of: Card, Conversation, and Confirmation. The method was first proposed in 2001 by Ron Jefferies, one of the founders of the Extreme Programming movement. Here is how the 3Cs are used:
- The Card (can be a physical index card or post-it note) used to store the concepts. It contains only enough information to identify the feature. Notes are written on it about priority and cost.
- The Conversation is the discussion between the stakeholders (customers, users, developers, etc.). The conversation is usually verbal but can be supplemented with documentation.
- The Confirmation ensures the objectives of the conversation have been reached. At the start of the project the customer communicates to the team what they want, by telling them how they will confirm they’ve done what’s needed. This is known as an acceptance test.
While user stories are an active part of an agile project workflow, if you have experience with another way of working you may be wondering, what other documentations need to be created.
Do user stories replace a requirements document?
While user stories replace most of the needs of a formal specification, it can still be helpful in some situations to have supplementary documentation. For example, user flow charts, or a database diagram. But in most cases additional documentation will slow the team down, so it’s best to go with the Card, Conversation, and Confirmation first, before adding anything else until it’s needed.
Now you have your backlog of stories, What’s next?
With your user stories in the backlog, the next steps are to sit down with your development team to prioritise what should be built and estimate how much effort each will take.
As we’ve covered, a core aspect of agile projects is embracing change when new feedback or information is received. If you are wrestling with a story that is too big or complicated, then breaking them into smaller chunks will mean your team can get closer to meeting the user’s needs in good time. Also remember that new stories can be added to the backlog as required.
If you have any more questions on user stories feel free to contact us and we will do our best to help you out.
Finally, if you liked this article, could you do me a quick favour and test out your newfound knowledge of user stories by doing some acceptance testing on this final story?
Scenario:
As a [reader of the Full Revolution blog], I can [sign-up for the free monthly newsletter], so that [I receive an awesome monthly newsletter, full of info and tips on creating digital products].
