Writing Good User Stories

User stories are a very good tool that helps focusing. Shifting the focus from writing lists and tables of requirements to talking about the use.

This is the fourth part of a series of analysis and creative techniques.

Introduction to User Stories

User Stories are short description of customers’ needs. All too often they are mistaken with Use Cases and Use Scenarios, but the biggest difference is that they are much shorter and do not describe the application interface, steps or flows in the application. While tools like the mentioned Use Cases and Use Scenarios try to be as detailed as possible the User Story can be defined and used as …

  • … the brief description of the need
  • … a communication and collaboration tool for the whole team
  • … the tests that confirm the story's satisfactory completion

User Stories are short and precise descriptions of features told from the perspective of persons who like to use a product or service. They typically follow simple rules …

  • … easy to understand
  • … simple and concise

In order to get such short and crisp sentences …

  • …  avoid confusing and ambiguous terms
  • … use active voice

The classic approach defining user stories is to describe it this way …
| Someone |, want | something | for | somehow | reason

… but often it’s either too vague who is the ‘someone’ and / or the action to do something is also uncertain – even I like these kind of user stories as UX planer and designer it hurts – because we neglect the context.

User related:

As an administrator (person), ...
I want (action) to enter new products into the online shop by entering product data and optional descriptions, ...
so that (goal) it’s easy to find and to understand.

Situation related:

When a product is ready to be published (situation), ...
I want (motivation) to develop a product detail page with the product related in order to cover the buyer’s expectation and needs; ...
so that (goal) the buyers can find the product, get informed and enabled to buy it.

How to start writing user stories ?!

Well my suggestion is using a template – such a template can help ensure that you don't start defining technical tasks by mistake. But that’s from time to time tricky because especially if the product or service is innovative and or offers new not so common features. In this case it’s often helpful to use a sequential approach. Think and write about the goals, aims, needs, context, and causalities - sketch the product functionality without committing to the details by writing overall and general descriptions. This is principally supportive for new products and new features, that gains you time to become familiar with your customers, users and how to best meet their needs. I love to use the personas with their goals to build the right basement.
When you have these overall and general descriptions – you have to break them into smaller, detailed stories until they are …
  • … clear
  • … feasible
  • … testable

Everyone should have a shared understanding of the story’s meaning. A story should be small enough to be coded and tested within an iteration. It’s often like walking a tightrope defining a good user story. Long and general stories, often named as ‘epic’, should be broken down into smaller chunks, but not so small that you've moved into detailed design.
When you have your stories group them into subjects and cognate disciplines. Using subjects helps you organize your stories. Cognate subjects make it easier to check for completeness and consistency,
Write your user stories on index cards or sticky notes and arrange them on a white board, pin board or wall – or where ever as long it’s visible and improves discussions.

As personas user stories are meaningful for each team member and helpful in each project phase – both should be organized and visible for everyone on walls or tables to facilitate, enable and simplify planning, design, and development and discussion.

You might also be interested in these articles...


Card Sorting


Swim-lane-diagram a great tool for alignment and process planning