When user stories are used well, they are a fantastic tool. When they are used poorly, they are a horribly burdensome micromanagement tool. Here are 5 things I commonly see people get wrong with user stories.
1. Prescribing solutions in user stories
Have you ever seen a user story like this?
As a user
I want to select checkboxes and then a red delete button
So that I can delete multiple students from a course
That ‘user story’ isn’t a story at all. It’s a requirement disguised as a user story. It prescribes a solution.
A user story is just that – a story about a user and their wants and desires for how their life could be a little bit better. When a user story is written well, it leaves a lot of creativity for a team to brainstorm solutions and determine what will best solve that user story. Here’s that same user story written in a way that leaves solutioning to the team:
As a course manager
I want to delete multiple students from a course
So that I don’t have to waste my @$#% time deleting them one by one
2. Calling everything in a product backlog a ‘user story’
A user story is a specific process and format for creating requirements. If you call everything a user story, then nothing is a user story.
3. Writing user stories for everything
I’ve seen teams spin out for 15 minutes trying to create a user story for something that everyone already understands. It usually doesn’t make sense to create a user story for everything. Sometimes it’s not worth the effort or it’s just not appropriate to describe a requirement as a user story.
4. Most user stories begin with “As a user…”
Something that makes user stories popular is that they quickly state who, what, and why. The most important part of user stories is the ‘who’. Without that, the what and the why don’t have context, and you’ll probably end up building something that doesn’t really meet the needs of your customer. Instead of starting user stories with “As a user”, be clear about who your user is. Here are some real-world examples:
“As a mother seeking preventive healthcare for a child”
“As a course manager”
“As a healthcare benefits manager for my company”
“As a Susan”
5. The product owner creates all of the user stories
User stories are supposed to be just that – a story. They are supposed to be very simple and could be created on 3” by 5” index cards. Anyone can create them – product owners, stakeholders, or team members. A user story is a prompt for a team to have a conversation with the customer about that user’s story to learn what they want and why they want it. That conversation should result in clarified expectations, commonly called acceptance criteria. This acceptance criteria gets your customer and your team on the same page about what’s needed and how it will be used.
This process bridges the gap between the people building solutions (the development team) and the people who are asking for those solutions. If done well, it reduces the risk of missing requirements and building the wrong thing. When a product owner creates all user stories without involving the team, that communication gap still exists.
