4 Common User Story Mistakes and How to Avoid Them

A few weeks ago, we gave you a breakdown of the basics behind user stories. Now that you know what they are and how to write effective user stories, there’s one more thing to learn: How to avoid writing bad ones.

There are a few common mistakes that happen when writing and developing user stories. Anyone who has worked on a scrum team or has written stories in the past has likely made all of these mistakes once (and usually more than once).

Here are five common mistakes you might make when writing user stories, and what to do instead to avoid them.

1. The user story defines the “how”.

User stories are specifically written to describe the what, why, and for who – but not the how. A user story should not describe to the developer how to accomplish the feature. It’s intentionally left open-ended to allow the creator freedom to decide how to best accomplish the end goal. This might be one reason why developers creating in an agile environment have been found to have higher job satisfaction than in non-agile environments. They’re more able to influence technical decisions and tend to have a higher autonomy.

A non-technical product owner or client will have no problem avoiding this one, but one with a technical background (maybe a former developer or someone playing the role of product owner and developer) may be tempted to influence the decision-making for specific processes.

How to avoid it: Give your team the ability to be honest and correct you if your user story includes too many technical directions. If you’ve committed this user story sin, it’s likely your team has already noticed. If you’re reading this and worry you’ve been guilty, bring it up in your next retrospective and ask for honest feedback. Going forward, ask yourself if your user story answers, “How will this feature be achieved?” If it does, remove it.

2. An unclear “user”

It’s important to clearly define who the user in each user story is. It can sometimes feel silly typing the same type of user over and over, but it does matter. Often products have multiple end-user roles or personas. The more specific you are in describing this role in the user story, the more tailored the end result can be for this person.

This is particularly important if you’re building a product that has multiple types of users – like an admin and a customer. Some features will be built for the admin’s benefits, and others for the customer. It’s important for your developers to know the end-user that will benefit from the feature and have their preferences in mind when building it.

You might also have two or more distinctly different personas of customers who are using your product, like a banking app that is used by both personal and business accounts. Each of these personas may have different primary uses for your app, even though the basic functionality will be the same.

How to avoid it: If your app interacts with multiple personas, clearly describe the user in each user story to avoid confusion. This means the “As a…” statement won’t just say “user”, but will describe exactly who will benefit from this new feature.

3. The “so that…” portion features requirements, not value

Like we explained in our first blog post on user stories, user stories are generally written in the format: As a (type of user), I’d like (end goal) so that (reason for end goal).

The “so that” statement at the end of each user story should describe the business value of the end feature for the user. What often happens is this statement describes the specific function that the development team needs to build instead – it’s easier to think up and describe because it’s more tangible.

How to avoid it: Double check your user stories to make sure you’re describing a benefit for your end user instead of a technical feature.

4. Broad user stories

This issue is self-explanatory, and perhaps the most common one that occurs when writing user stories. It’s very, very difficult to break down feature ideas into small user stories. It takes time and practice to get good at, so don’t expect to get it right on the first try. And you likely won’t actually realize your story is way too big until you’re nearing the two-week mark in your sprint and the story is nowhere near complete. But after a few sprints worth of work, the entire team will surely notice when stories are too big and need to be broken down further.

How to avoid it: Always start with an epic and work down from there. If you have an idea for a new feature for your app, it’s likely that this broad idea isn’t a story, but an epic. There will be many user stories within this new idea.

Let’s go back to the banking app example. Based on user feedback, you decide to implement a new feature in your app: the ability for personal and commercial users to transfer money to outside accounts.

While this seems like just one feature, there are many layers to accomplishing the desired result. A user would need to view and add an external account, an admin would need to verify and approve this external account, there needs to be an interface for the user to choose how much money to transfer and when to schedule the transfer – and that’s just the most obvious steps.

---

If you're new to writing user stories, or developing products based on them, these common mistakes will happen. By knowing what to look for, and what to do when you encounter them, you'll be better prepared to write effective, concise user stories in no time.