Are you still writing user stories like this?

This is a follow on from our checklist for writing user stories and how to identify when a user story is "ready" for dev.

1. Too detailed

Yes, you read that right. User stories can have too much detail in them.

The purpose of a user story is for the Delivery Team; Product Owner, Designers, Developers, and Testers, to collaborate and find the best solution for the end user, or customer.

By writing the user story in too much detail you restrict the opportunity for collaboration, and start to solutionise, taking away emphasis on the end users needs.

An example of an overly detailed user story is:

“As a fitness app user, I want to login to the app using my Facebook account, my profile and friends list should all be imported and all of my recorded workouts should be shared with them on Facebook.”

The example above is so detailed that there is no room for discussion around other potential solutions. Does that mean someone who doesn’t have a Facebook account will be able to use the fitness app? Would all users want to share all of their workouts? 

2. Too vague

On the other end of the scale user stories can be too vague, as a minimum user stories should outline the user, and their needs. Take the example below:

“The app needs to work flawlessly.”

OK, who is the user? What is the context of their app use?

Hopefully it's obvious that ‘flawlessly’ is a vague and subjective term, but we have seen broad statements like this in real user stories. (see also: 'world class') 

The scope is too broad, and doesn’t provide clear direction on what flawless looks like, or why this is beneficial for the end user.

A few tweaks to this user story and it could look something like:

“As a banking app user, I want the app to inform me when it is loading or an action is in progress, so that I know it is still working and hasn’t crashed.”

Having a user story with an undefined user and poor context can lead to needless time wasted on discussions on how to achieve an unachievable solution.

Rewrite the user story this by putting yourself in the user's shoes, and thinking about their needs.

This will allow the Delivery Team to have more focused discussions on the solution and bring real value to your end user.

3. Too broad

User stories should be deliverable within one sprint (typically 2 weeks), if you can think of a number of factors that would go into implementing your user story, then it’s probably too broad, and you should look to break it down into multiple user stories, for example:

“As a customer, I want a website.”

The example above is likely an epic rather than a user story, as it can be broken down into features and user stories, like so:

Epic = I want a website

Feature 1 = The website should have checkout functionality

Feature 2 = The website should have functionality to view products

User story 1 = As a retailer, I want the website to have a basket and checkout functionality, so that customers can buy our products online.

User story 2 =  As a customer, I want to be able to view a products images, description and price, so that I can decide if I want to buy it or not.

In Summary 

A good user story needs to be in that Goldilocks zone - not too broad in scope, nor too narrowly constrained with solutions (unless there is a strong user-driven need for a particular approach). 

You need to be specific about the requirements and acceptance criteria, but that needs to be grounded in user needs and expressed in language that can be checked objectively. 

For further guidance on how to construct your user stories, see our checklist for writing user stories and how to identify when is a user story "ready" for dev?