Do Not Make These Mistakes When Writing Your User Stories

Proper User Stories are essential in an Agile development environment. Here are the mistakes I often see. Know them. So you can avoid them.

User Stories are descriptions of features told from the perspective of a person who wants the new function. It usually follows the template: “As a (type of user), I want (goal) so that (reason).”

The bulk of the User Stories are written near the start of a project. Resulting from either a workshop or design sprint. (That does not mean you can't add them during development).

Anyone on the team can write User Stories. It's not only the Product Owners' task. However, the POs do make sure the Stories end up in the backlog.

Writing the User Stories without discussing them, means you only did half the work.

The main purpose of the Stories is to start discussions. Those discussions with the team often result in flows, information architectures, technology decisions, and other requirements. So, I recommend documenting these meetings.

Writing User Stories without discussing them, means you only did half the work. You slacker.

Watch out for the following errors when working with User Stories.

The 4 Most Common Errors

There are several recurring fallacies in User Stories. I have written down the ones I see all the time. Do not make these mistakes. It'll hurt your project.

1. Describing How A Feature Functions

User Stories should not tell the team what to do. The solution is up to the team to decide. They are the professionals, after all.

"As a user I want a button that…". No. Don't.

User Stories should not include any solutions or opinions. Adding a potential solution results in the wrong thing talked about.

2. It Does not Lead to the Proper Discussion

Consider this example of a lacking User Story:

'As a power user, I would like to change the backup settings, so that I can save space.'

Undoubtedly, the team will have questions. What kind of backup settings? Save space where? In the cloud?

The Story needs to be more precise.

Write User Stories in a way that will guide the discussion in a more focused, valuable direction. Talking about the ambiguity of the User Story is a waste of time.

3. The Reason is Actually A Copy of the Goal

I have heard the 'goal' repeated as the 'reason' since day one. That's a lazy Story. 'As a player I want to save the game, so that I can save the progress.'

That's not the reason. The reason is that you would like to be able to come back and continue where you left off.

Be wary of obvious sounding User Stories. They lack context and are not a starting point for a helpful discussion.

4. Trying to Squeeze out a User Story of Something That Isn't

Guess who wrote the following ticket.

'As a user I want to see the logo in the app, so that I know what business I am dealing with.'

You guessed it right. It's someone of the C-suite.

If this is a business goal-oriented requirement, fine. But, do not label it as a User Story because it isn't. Add it as a task. (Adding a logo in the app is a bad idea, by the way.)

I have three things I would like to leave you with:

  1. it is important that every team member knows how to write a good User Story.
  2. And, it's more important to discuss the User Stories with all the stakeholders.
  3. For optimal results, make the User Stories always visible to the team. Put them on sticky paper on the wall, or in a digital solution. Keeping them visible will raise questions also outside of formal discussion rounds.

Pro-tip: An anonymous suggestion box near the wall of stickies will surface questions considered 'too dumb' to ask.

What is the most horrible User Story you've ever come across? Share it in the comments.

Share this article:

Leave a Comment, Get Reply

No sign up required (enter name › 'post as guest').