Everyone wants to go Agile today. Teams want to put the user in the center of their product development process while building products. After all, you are building the product for your users, right? User stories are one of the basic tools that help teams keep the user in mind while defining the product and its features. A lot has been talked about . And there are many who prefer an . ( ). how to write user stories alternative method Here’s another one And I can certainly understand why they’d prefer other variations. 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 never stops with one misjudgement. In this article I will talk about some of the common mistakes teams make when writing user stories. 1. User stories that are too broad When user stories are too broad, crucial information regarding the expected action and the need can get missed out. If there are a lot of “ ” or “ ” 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 . ands ors epic 2. User stories that are too fine When user stories are broken down too fine, 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. 3. Not being negotiable User stories are not meant to be specific, precise description of a feature. And must not be fixed in stone. Here’s a classic scenario to 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 uneasy 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. 4. Reiterating the user story in acceptance criteria allow you describe conditions that need to be met for the story to be marked as completed. It ensures that you gather feedback, help the team plan, and track their work. It makes the user story more rich, precise, and testable. Acceptance criteria 5. Having an undefined user It can feel silly to mention the user persona in every user story, but it can add a tremendous amount of value in terms of the outcome. This particularly is 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 to 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. 6. Poor context Far too many times, we end up writing user stories for the sake of it. After a point, nearly every user story starts to look the same. ” ” 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. All it takes is really one tiny mistake in the process for you to find yourself in a pile of mess.

BUNCH

Five Steps to Positioning Your Product

What it Takes to Get Your Team to Collaborate in 2019

Building JIRA alternative for software product teams

Read My Stories

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

6 User Story Mistakes That Cause Confusion During Product Development

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Acceptance Criteria Mistakes Teams Should Avoid

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

5 Acceptance Criteria Mistakes Teams Should Avoid

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps