User Stories and Personas

A user story is a way of describing a website or product feature in relation to the person who will use it, how they will use it, and why it is useful.

User stories usually follow the format “as a [role], I want to do [task], so that I can achieve [goal]”. This can also be written “as who, I want what, so that why”.

The role, the task, and the goal are all equally important, and a user story is incomplete without all three being present.

The role should not be merely an unspecified user of your website, and this is where personas come into the picture.

A persona is a description of one cohort of your target audience. It should have a name, and some details about why and how they would want to use your product or service. Here’s an example of a user persona for Carnelian Web Services:

Adding details to personas and making them like a real human with a life story reminds us that we are developing content, products, and services for real human beings.

Personas provide epics

Once you have developed your personas, you’re ready to write user stories which express the business requirements of your personas. Here are some examples for Tamara:

1. As Tamara (a small business owner), I want to be able to sell my products online, so that I can expand my customer base.
2. As Tamara, I want to be able to email my existing customers, so that I can let them know about new products.
3. As Tamara, I want to be able to publish my products on multiple social media platforms, so that I can show them to more customers.

In reality, the three examples above are going to be large projects (known as epics), so they will need to be broken down into smaller chunks. These may include a spike (a time-boxed activity to discover the best way to solve the problem).

Epics can be broken down into user stories

The first epic (selling products online) can be broken down into a spike to find the best e-commerce platform for Tamara’s needs; configuring the platform to her requirements; setting up billing and payments (Stripe, WorldPay, PayPal, etc); integrating it with her existing website; uploading her logo and products. Later, there may be bug fixes or enhancements to add.

The second epic (email existing customers) would include a spike to evaluate the best tool for the job (MailChimp, HubSpot, etc). It would be prudent to select a tool that can help with the third epic (publishing to multiple social media platforms). Other user stories in this epic would include setting up email templates, uploading the email addresses of customers, and setting up a contacts management system.

The third epic (publish my products on multiple social media platforms) would include ensuring that Tamara’s business has a presence on Facebook, Instagram, Threads, LinkedIn, Google Business, TrustPilot, etc. It would also involve enabling her to publish to all these platforms simultaneously, schedule posts for the future, and configure posts differently for different platforms.

User stories should have acceptance criteria

The acceptance criteria are the requirements for the story that make it a shippable feature, able to be published to your website and used. They are useful for defining the task for the developer, and they form the basis of what the QA tester will check before marking the story as complete.

Sometimes it helps to write acceptance criteria in the “Given, When, Then” format, if the feature will behave differently depending on whether the user is logged in or registered. Sometimes you just want to write a list of what the feature should do.

Here’s a “Given, When, Then” example:

Scenario: Logged-in user on the website buying a product
Given I have added an item to my cart
When I press the checkout button
Then I should be able to add a billing and shipping address

Here’s an example list of what the feature should do:

• Option to go back to the store and add another product to the cart
• Ability to remove an item from the cart
• Option to add a billing address
• Ability to indicate that my billing address is the same as my shipping address
• Option to add a different shipping address
• Ability to check out
• Option to pay with different systems (Stripe, Interac, WorldPay, Apple Pay, Google Pay, PayPal)

Each of the above could have its own user story and “Given, When, Then” scenario.

Writing user stories is more of an art than a science, and different teams will require different ways of breaking down the tasks into manageable chunks.

How you break down and organize your user stories depends on whether you are shipping a new version of the product every day, every week, every month, or every quarter.