What are user stories?

User stories are part of an agile technique that helps shift the focus from writing about requirements to talking about them. Usually all agile user stories include a written sentence or two and more.

Who, what, why?

User stories usually answer the questions of who and what and why. It should be written by the business in the language of the customer. This means it should be clear to both the business and the development team what the customer wants and why he wants it.

Here are examples of a user story:

• As a user, I want to upload photos so that I can share photos with others.
• As an administrator, I want to approve photos before they are posted so that I can make sure they are appropriate.

Characteristics of a well-formed user story

Working with user stories is easy, but telling effective stories can be hard. Here are some tips to create good stories.

Small and simple. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability – usually a user or customer of the system. One of the benefits of agile stories is that they can be written at varying levels of detail.

Discussion. User stories focus from writing about features to discussing them. These discussions are more important than whatever text is written. That is because written language is often very imprecise and there’s no guarantee that a customer and developer will interpret a statement in the same way. Be prepared to develop your stories. And most importantly – especially when they are for a specific customer  – get the main users of that feature to verify them and even be involved in their creation.

Business value.  The purpose is to provide business value. That means it should determine the health and well-being of the application in the long run.

Estimatable. It must have enough definition for the developers to provide an estimate of the work involved in implementing it.

Testable. User story should be testable and understandable for all team members. Add the main acceptance criteria during the process of agreeing on a story. Customers, product owners and other interested parties should all have opinions on what these are. Each acceptance criterion should become a test in the development process. This enables a story to be checked if it satisfies its most important needs and limitations.

Here is an example of how our example user story is developed with one of many possible acceptance criterion:

• As a user, I want to upload photos so that I can share photos with others.
• Acceptance criteria:
  – Reduce the size of a photo being uploaded to a limit of 200 kB automatically.

Independent. Each user story should be independent of any other user story.

Who writes user stories?

User stories are written throughout the agile project. Usually developer, project manager or product manager writes user stories. UX teams are sometimes responsible for writing stories too, but not as often. But they’re not the only ones who can (or should) write user stories. It’s unlikely you’ll get marketing, sales or customer support interested in writing user stories on their own.

You might also be interested in this article:

Non-technical explanation of an API

User stories explained on Wikipedia.

—–

PlanMill Ltd. is a leading provider of user-friendly web-based CRM, PROJECT and ERP Cloud solutions designed for the service business. We enable organizations to streamline business processes, improve control of their customers, personnel, projects and finance – while enhancing productivity and profitability.