Writing Effective User Stories: 5 Essential Rules

Intro

As far as I know, there are at least a million ways to write User Stories, and that sucks. Some of them are good approaches and some are just crap, more like full-blown specifications from the old days. In the past 10 years, the way I write User Stories has evolved from the Stone Age to a more modern century. I guess it’s like real life, everything evolves and it will always be somewhat wrong in retrospect.

Anyways, I’d like to share some ideas on how I write User Stories today.

Boundaries

From my point of view, a User Story delivers value and to be specific, one User Story delivers one user value. I’ve read so many Stories where it goes like this: "As a PO I want to bla bla and bla bla bla and after that foo foo foo, so that x, y, z." Well, there are a lot of issues with this example. First of all, what kind of User is the PO in this Story? Maybe they are developing a Scrum Tool, which in this special case would make sense. Otherwise, it's just one lazy Product Owner. The second issue with this Story is the concatenation of user values. It seems to be one Story, but by using conjunctions, this tiny little Story swells to a bigger picture, maybe a Feature or even an Epic.

So, to be more specific, I try to follow these rules when writing User Stories:

1. One Story, one User Value
2. Try to follow the "As a [Role] I want to [Function], so that [Goal]"-Template
3. Always define User Roles, like "Administrator" or "Customer" and so on
4. Try to specify Personas based on your User Roles, to be even better in describing your User Value
5. Always make your User Story testable from a user's perspective.

Deep Dive

Let’s have look at my list of rules and what I mean by that.

One Story, one User Value

It’s super important to write a User Story which tries to generate just one User Value and not a list of values. Why is it important? Well, one value is much more easily testable in the end. Also, one value is, if necessary, easier to break down into development tasks. Another positive side effect is that one value can be delivered much faster.

Try to follow the User Story-Template

Back in the old days, when User Stories first came up, a story consisted of a simple card. On the front was written something like "A company can pay for a job posting with a credit card" and nothing else. At the back of this card, you could find some tests to make sure your User Story delivers exactly what you want. You may ask, what is wrong with this approach? In short: nothing. But, User Stories are much broader in use now, and many more people are making use of it, even if they have no experience with it. To prevent people from writing a novel instead of a User Story, the User Story template has been invented. It helps to nail your expected goal down to just one value. And if your goal does not fit into one value, well then you have to write more than one User Story.

User Roles

A User Role is someone who is using your application. For example, if you want to create an online book shop, you have at least 3 roles:

1. The Customer
2. The Seller
3. Page Administrator

Based on these roles, you can write better User Stories to deliver specific value to them.

Personas

In addition to Roles, you can develop Personas. Personas provide a more in-depth look into a User Role. For example, a Persona for "Customer" could be "Susan the Customer".

Susan the Customer

• Demographics:
  • Age: 23
  • Interests: Volleyball, Finance, Dogs
  • Digital native
• Background: Susan is an Accountant and wants to teach herself to get better in her job.
• Goal: An easy way to search and buy business books

You see, based on this Persona, you can create a User Story which provides much more value to your user base.

Testability

In order to create a User Value, you have to make sure that you deliver the right thing. To ensure this, you have to test your User Story. There are a lot of ways to test a User Story, and it doesn't start at the end of the implementation. An experienced development team will test their implementation with each commit to make sure nothing breaks. Also, an experienced team will always try to reflect the User Value and consult the Product Owner to ensure they are doing the right thing.
Another significant point when it comes to testability is to test the User Story from a user's perspective. A user will never test if property "Age" is persisted in your database. A user wants to add their age via an input field, refresh the page, and still see their age.
You see, there are several layers of testing within a User Story:

• Unit Test
• Integration Test
• System Test
• User Acceptance Test

A good development team is able to deliver all testing stages for each User Story in one iteration. But the overall goal for a User Story is to verify that the user value, which is described, is delivered correctly.

Summary

I hope my point of view was helpful and you can see why I think there are a lot of bad User Stories out there. My goal was to deliver a quick guide on how to write good User Stories, simply by sharing my list of rules.