User Stories - Capturing the User’s Perspective Quickly and Simply

User stories are a simple tool for articulating the user’s perspective. They are not long, wordy stories to be told around a camp fire but rather short (often only a single sentence) descriptions of what a user will do with a part of a system. They are written in plain English or in the language of the business in which they will be used and require no special literary gifts or linguistic talents to compose.

They are particularly important in Agile environments where they facilitate the functionality of a system but can be used in any environment to ensure that design and development are focused on user needs. They deliver the “who”, “what” and “why” of user requirements in a format that can be easily understood by anyone who needs to use them.

The Background to User Stories

The user story was first described in Extreme Programming back in 1998. It was mentioned that user stories could be used to define scope of a development project in a similar way to use cases. (Use cases are visual descriptions of actions taken by a user which are usually recorded in UML – Universal Markup Language).

Author/Copyright holder: Slashme. Copyright terms and licence: CC BY-SA 4.0

UML use cases are visual diagrams that capture requirements and actors – they are very different from user stories.

However, it is commonly agreed today that a use case and a user story serve different functions. Use cases address how a requirement will be handled whereas a user story simply captures the requirement.

Author/Copyright holder: Paul Downey. Copyright terms and licence: CC BY 2.0

Always capture user stories in a way that feels useful and doesn’t interfere too much with the user/client conversation – you can always revise them later.

Writing User Stories

In many cases user stories are not created by the design or development team – they’re provided by a customer or a business user to try and explain what they’d like the finished product to look like. However, that doesn’t mean that in the absence of customer/user provided stories that the team cannot create their own. In larger organizations, this responsibility may be covered by product managers in other organizations it may fall within the remit of the UX team.

While, in the main, a user story is going to capture a requirement of the product functionally they may also be used to describe non-functional capacities of products too (for example privacy or security requirements).

As Steve Rogers, the well-known designer said; “Designing a product is designing a relationship.”

To form that relationship, user stories are always best when created with the input of users or the end client and can easily be facilitated by a designer or developer working in conjunction with a representative of the user/client base.

The idea is to use a simple question and answer format to develop the story. Then the designer or developer records each story on a single card. This story may then be revised for clarity after the requirements capture exercise is complete.

The generally accepted format for user stories is:

“As a , I want , for this ”

This format was proposed in 2001 by a team working for Connextra in a story related to AgileCoach at Typepad.

There are many variants on this theme but all of them capture a similar set of information.

Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0

As you can see here – user stories, captured one per card, can then be easily presented back to the development and design teams as necessary.

User Stories and Agile Development

User stories are used in agile to define all functionality of the final product. They are not set in stone and it is completely accepted that requirements can (and often will) change throughout the lifecycle of a project.

The scrum master (the agile team leader) then prioritizes the stories for development in each sprint. Developers are often given carte blanche to discuss user stories with the end user or customer in order to fully understand what is required of them.

Agile also requires that each story have a corresponding test case or test cases attached to it for UAT (User Acceptance Testing). This way the development process ensures that the story is implemented in a manner that is satisfactory to the user. It also provides a basis for negotiation if a user story is implemented correctly but does not satisfy the end user.

Benefits of Using User Stories in Design and Development

There are several benefits of using user stories in design and development cycles:

They are simple and quick to understand.
They allow programmers to quickly (using agile) implement customer/user value
They don’t need very much maintenance
They can be discounted except when they are being used in development
They allow a project to be chunked into smaller milestones
They make it easier to estimate costs on a project for development
They facilitate cooperative working with clients and users

The Drawbacks of Using User Stories in Design and Development

There are possible drawbacks of using user stories and in particular of becoming overly-reliant on them at the expense of other tools:

They are difficult to work into large scale projects (where thousands of stories might be required)
They may be too vague to be useful and require a lot of back and forth between developers and clients
They fail to capture performance measurements and sometimes non-functional aspects of the system – e.g. they are too simple

Author/Copyright holder: Wiggy! Copyright terms and licence: CC BY-SA 3.0

A user story’s simplicity can be its greatest strength and its greatest weakness. Don’t forget you have to capture enough information to deliver on the intangible requirements as well as the tangible ones.

The Take Away

User stories can be very useful to articulate the user’s or client’s requirements for a system in simple one line (or very short) stories for each requirement. They fit neatly into the Agile development method and ensure clear understanding of what’s needed from each sprint. However, it’s important to remember that user stories also have limitations and their use should be carefully considered to ensure that all requirements and performance measures are understood before design turns into development.