Four ways to improve your user stories

User stories are a great way to keep conversations open while building up the requirements for new features. However, it can be tricky to write in the common “As a <type of user>, I want <something> so that <some reason>” format at first. This post explores four ways you might be able to improve your stories.

Suppose you’re the owner of a growing site dedicated to blogging. It’s very basic and user’s have started to complain that they can’t find what they’re looking for because there’s too much content for them to scroll through. One of your developers decides it’s time to do something about it and writes a story for the backlog:

As a developer
I want to create a tag filter

Great! A place to start. Unfortunately, this story has been written from the perspective of the developer and, without any context, means very little on it’s own. It isn’t clear what benefit there would be in adding a “tag filter” for someone who is non-technical.

Include the user

Users should be at the heart of every decision we make for a product. In our example, we understand that the developer has set out to solve a problem for users but it’s not clear that this is the case. It has ended up sounding like a technical task which could be dismissed as low value to non-technical team members. Instead, phrase a user story from the perspective of a user or a type of user:

As a user
I want a tag filter

It’s now clear that someone believes there is benefit to the user in adding a tag filter but it’s still not clear what that benefit is.

Add value

User stories are designed to promote communication and conversation. As it’s not clear what the benefit is, it’s not going to be clear whether this story is more or less valuable than the next. Before this story can be prioritised, a conversation needs to happen to determine what the value really is.

As a user
I want a tag filter
So that I can filter blog posts

The above is better as it’s now clear to anyone reading that a tag filter will allow the user to filter blog posts. However, does it demonstrate the value? This story now raises the question of why the user would want a blog post filter. The “reason” has become a duplication of the “something” that the user wants, only with slightly less detail.

No really, add value

It’s easier to write about value if we consider the problem that’s being addressed. If we look back, the problem is that users are struggling to find content because there is too much of it. The user would benefit from a way of finding the content they need without having to scroll through reels of content:

As a user
I want a tag filter
So that I can find relevant content more easily

It’s becoming much more clear now what is needed, who needs it and why they’ll benefit from it. However, there’s one more improvement we can make in order to open up conversations a bit further. The developer that wrote the story already had a solution in their mind, a tag filter. However, this may not be the best solution to the original problem.

Keep options open

In order to keep the options open until scope/costs/timelines are fixed, it’s better not to constrain the solution down too tightly:

As a user
I want to filter blog posts
So that I can more easily find relevant content

By specifying only that the user wants to filter posts, rather than that they want a tag-based filter, opens the door to other potential solutions. Instead of defining the solution in the user story, use acceptance criteria which define the desired behaviour but leave the team implementing the feature the space to provide the best solution.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s