There's a lot of information out there on how to write user stories and why it's important. And yet, many of us make mistakes that cost us a lot.

There are many who even prefer an alternative method. (Here’s another one.) And it's often because they're frustrated by poorly written user stories.

As much as it's important to know how to write good user stories, it's equally important to know how to NOT write one.

Today, many software teams want to adopt agile processes. They want to put the user in the center of their product development process while building products. And it makes perfect sense. After all, you are building the product for your users, right?

A lot of times when writing user stories we think we are writing from the user’s perspective, but we end up skewing it with our biases and knowledge. And a lot of times, these mistakes are interlinked and only get worse with time.

In this article I will talk about some of the common mistakes teams make when writing user stories.

User stories that are too broad

When user stories are too broad, crucial information regarding the expected action and the need can get missed. If there are a lot of “ands” or “ors” or "thats" in your team’s user stories, it is good indication that it is too broad and you should consider re-writing it.

Also, there’s a very good chance that your too broadly written user story is actually an epic.

An example of a broad user story might look like this:

“As a user, I would like to continue reading the article later when I’m on my way home, without needing to sign up and find the exact spot where I left off.”

In this case you can see the user story is trying to achieve two things — not needing to sign up and not having to find where they stopped reading. Instead of trying to cram everything into a single user story, consider breaking it down into multiple user stories.

Here's how it may look after it is broken down:

"As a user, I would like to continue reading the article later without having to sign up"

"As a user, I want to continue reading from where I left off, so that I don't have to find the last paragraph I finished reading"

User stories that are too fine

When user stories are broken down into too much detail, you begin talking about how you are going to implement it. This removes the focus from the user and leads to poor communication of expectations within the team.

Here's an example of a user story that is defined too fine that it talks about implementation details.

“Define a scalable, relational database structure so that I can use it to implement any possible future use case.”

What business value does a great relational database have if the end user cannot use it? Besides, this user story is written from the business' perspective and not from the user's perspective. When you begin to include the implementation details, user stories no longer are written from the user's perspective.

User stories that aren't negotiable

User stories are not meant to be specific, precise descriptions of a feature. And therefore, they must not be fixed in stone.

Here's an example of a non-negotiable user story: "As a user, I want to have a clear all button in the notifications tab, so I can remove old notifications"

You can clearly see, the user wants to be able to remove old notifications. While having a "clear all" button is one solution, you can still automatically clear the notification after it's read too!

Here’s a classic scenario to help you identify if your user stories are too rigid:

Sometimes a user story may have been written in a particular way, and your team finds it hard to implement because there’s an easier alternative.

In cases like these, the team should be willing to compromise on the approach provided it doesn’t hurt the value a user derives.

User stories that are reiterated in acceptance criteria

Far too many times I notice the acceptance criteria repeating the user story, just in different words.

Here's how it looks:

User story: "As a user, I want to add pop-up forms to my blog, so I can capture the visitor's email id before they leave the site"

Acceptance criteria: "Given a reader visits a blog, when they try to leave, then the pop-up form should come asking them to subscribe to the blog"

Acceptance criteria should communicate the conditions that need to be met for the story to be marked as completed. This ensures that you gather feedback, help the team plan, and track their work. It makes the user story richer, more precise, and more easily testable. And more importantly, it aligns your team on what they're expected to deliver.

Here's a better example:

For the user story: "As a user, I want to receive notifications when others add comments so that I am up-to-date."

Acceptance criteria: "Given I have the app open when I am writing on the doc then the bell icon should update to show unread notifications with count"

User stories that have an undefined user

It can feel silly to mention the user persona in every user story over and over and over. However, it can add a tremendous amount of value in terms of the outcome.

This is particularly important if your product has more than one user persona. There will, of course, be features that’ll get built specific to different personas. If you want your team to be more aligned on the outcome you are expecting out of them, they need to know who the end users are and what benefit they’ll get out of the feature.

If you're looking for an example for this, nearly all examples I provided above are great ones of how not to do. Don't worry, it was intentional so I can talk about this. :)

Every time you write a user story that begins with "As a user..." or "As a visitor..." or "As a reader...", you're leaving room for ambiguity. Clearly defining who that person is will go a long way in giving your team the context they require.

At Zepel, we recommend writing the persona instead of user/visitor/reader. This means, your user story will look like this:

"As a writer, I want to receive notification when others add comments within the Google Docs app, so I don't have to refresh the page every now-and-then"

User stories with poor context

Far too many times, we end up writing user stories just for the sake of it. After a certain point, nearly every user story starts to look the same.

Here's an example: "As a content manager, I want a text editor so that I can edit text."

All this tells your team is that you want them to build a text editor and nothing else. If you’ve been writing down a bunch of user stories for a while, it’s best to take a break and revisit it with a fresh perspective.

Sometimes, even after a break, you might not be able to come up with something more meaningful. This can be a good indicator that you need to talk to your users more and understand their needs better. There’s really no point trying to squeeze it out of your brain.

Conclusion

Although using a user story template can be useful, it is never as simple as completing a fill-in-the-blanks form in your agile tool.

Because one mistake while writing user stories often leads to a series of other mistakes as a by-product. And even if you do manage to write user stories properly, it’s only the beginning. You should still enable your to team to analyze the stories — from a technical point of view — to help them estimate and create the necessary next steps.

User stories are a great way to plan development work. In theory. But how do you avoid getting burned in practice? I propose a radically simple approach.

Here's a popular template to describe a user story:

Here's an example user story:

User stories look at software from a perspective of user value. After implementing a story, the developers can get feedback from users whether they're satisfied or if there's something they'd like changed. That's the core idea of agile development.

Good user stories follow the three Cs: Card, Conversation, and Confirmation [1].

Card means: user stories are short. They focus on the value provided to the user. You can write them on an index card, or a Post-it. Of course, a Post-it doesn't contain all the information necessary for development.

So the team developing the software has conversations about the stories. Input from users and business stakeholders is necessary, but developers bring their ideas to the table as well. It's important that everybody keeps an open mind in these discussions.

The team documents the results of the conversations as acceptance criteria. Checking the acceptance criteria later serves as confirmation that the team has implemented the story correctly.

Acceptance criteria and INVEST

The acceptance criteria should answer questions like:

• What are the possible user inputs?
  For example: "The payment options are MasterCard, Visa, [...] PayPal."
• How does the system react to user input, or a business relevant event? Under which conditions?
  For example: "When the user enters a wrong credit card number, the system shows the following error message: [...]"

There are many ways to document acceptance criteria. Bullet points, sketches, examples, tables. Development starts a few days after the conversation about the story. So developers need just enough documentation to remember the conversation.

How does a team check if a story has a good enough quality to start implementing it? The INVEST criteria define a quality checklist for each story [2]:

• I for Independent. The story can be implemented independently of other stories. This facilitates priority changes.
• N for Negotiated. The conversation between developers and stakeholders about the details of the story has happened.
• V for Valuable. The story provides visible value for users. In contrast to implementation tasks like querying the database, for example.
• E for Estimable. The developers can estimate the story.
• S for Small. The story can be implemented quickly. In Scrum for example in a Sprint.
• T for Testable. The story is so concrete that the team can derive test cases.

The problems in practice

I like user stories. In product planning, they shift the focus from technical details to users and their needs. That's good.

And yet, in my work as an agile coach and trainer for agile approaches, I've started questioning the common way people deal with them.

I've seen backlogs with hundreds of stories that became extremely hard to manage. I've witnessed people use the terms "feature", "epic" and "business requirement" without sharing an understanding what that even means. I've heard endless discussions about detailed acceptance criteria, and how to slice stories based on them. It was frustrating.

I claim there is an alternative. A simple way to avoid all these traps. First, you need to understand that there are two fundamental levels of user stories.

Goals deliver value, but can't be implemented

In one of my courses, I ask questions like: "What can you do with a web shop?"
The typical answers are: "Buy a product", or "Order products".

What the participants talk about are goals. If we were a team developing a web shop, we might come up with the following user story:

Is this goal level story valuable to the user? Yes! It reflects the needs of the web shop customer.

Can you implement this goal directly? No! In order to implement a goal, you need to derive steps to reach it first. For the story "Buy Product", the steps might look like these:

Each step could be documented with the user story template: "As a web shop customer, I want to enter the address so that the product is shipped to me."

Can you implement this step level story directly? Yes! As soon as you have clarified the acceptance criteria. But is it valuable for the user? Without the other steps, no.

Value only emerges when the goal has been reached. Each step represents progress towards the goal. But independently, the step has no value. Does it make sense to use the story template for it then?

A radically simple approach

The stories at the goal level are coarse grained. They can be used for long-term planning, without wasting effort on details:

You can often realize good user stories at the goal level independently of each other. And they deliver value. They are Independent, Negotiated, and Valuable. But they are not Small, easily Estimable and Testable. Because you cannot define acceptance criteria for them without talking about steps.

The stories at the step level are Negotiated, Estimable, Small, and Testable. However, they are not Independent and do not provide Value alone.

How do you combine the two kinds of stories into one simple approach? Here's my proposal.

The team picks a goal, say "Buy product". The team then reflects: "What is the simplest way to reach the goal? And how can we reduce architectural risks early?"

Let's assume that the team sees the greatest risk in the communication with PayPal, because they've never implemented an interface to PayPal before.

So what does a simple way to get to the "Buy product" goal look like? The team puts goal level story, step level stories and acceptance criteria as stickie notes below each other:

Here's what the acceptance criteria say (green stickies). There is only one fixed product that can be ordered. No search, no choice. The user interface is basic, and only allows users to pay with PayPal.

These are the first steps that the developers implement. Once the developers have implemented a step, they demonstrate it to company internal stakeholders. At latest when a goal is reached, the team involves users. Getting feedback and deriving insights for further iterations is crucial.

In later iterations, the team adds and changes stories. Examples include: more products, a search capability, and new payment methods. Or the team picks another story as a goal. Whatever is most valuable and makes sense at a given point in time.

Summary

You focus on a few goals to look further ahead. But you only discuss the acceptance criteria of the steps that you will implement in a few days. You implement the steps and gather feedback. You use the feedback to inform what you will develop in the future.

That way, everybody has a clear idea of what happens in development. You avoid wasteful discussions. And you keep backlog management to a minimum.

I've followed this approach many times. When everybody involved is on board, it works great. It makes development a joy.

And that's it.

Sources:

[1] Ron Jeffries 3Cs: https://ronjeffries.com/articles/019-01ff/3cs-revisited/

[2] Bill Wake on INVEST criteria: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.