“Stories”, be they user stories or jobs stories, are very useful templates for communication across software teams. But sometimes they get abused.

This post describes a handful of examples of how user stories can be mangled, turning them into what I call ‘wolf in sheep’s clothing’ stories.

Pattern 1: …said no-one ever

“As a user I want a dashboard so that I can see how much X is affecting Y.” … said no-one ever.

• Said no-one ever.

Actually, someone did say this to me once, but I have opinions on conversations starting like this and they don’t end well. If a user story does not give insight into a real-world problem and instead prescribes a solution, there isn’t really a point to using a user story.

Ways to fix it

• Replace the want with need. Some user stories are just not very believable because they are not things that people want to do but things that need to be done anyway e.g. As a data enterer I want / need to file my report by 6pm so that my boss doesn’t shout at me.
• The want should be want to not want [a thing]. This helps us to focus on the action and leaves room for creative solutions. Encourage the person who wrote the ticket to reframe it as an action.
• Try and reframe it as a job story to focus it on an action.

Pattern 2: Giving feedback

As a user (!) I want the button to be blue and moved four pixels to the left.

Sigh. There is no so that in this formulation, perhaps because articulating the value of this change from the user’s perspective is nearly impossible, and the user story format has been contorted to deliver feedback.

Ways to fix it

• This should not be a user story. It is fine to have tickets which are not user stories, but using user stories to deliver design feedback both devalues user stories and obscures the feedback. Tell the person who wrote it that it is fine to provide feedback in the defined feedback process.

Pattern 3: As a generic user

As a user, As a citizen, As a government official etc.

User stories which contain user personas as vague as this are usually a sign that you don’t understand your user base well enough.

Ways to fix it

• Do more user research. If you are starting with personas this vague - chances are you don’t have personas, but proto-personas and should probably get out of the building and talk to people before you start developing.

Have more pathologies? Let me know!

There are lots of other ways that people break user stories. Let me know on Twitter or by email: lucy [at] techtohuman [dot] com.