A big part of how to write good user stories is to help teams find ways to organize their work in a way that follows agile values and principles. We order that backlog by value trying to build the highest value first.

User Stories are agile in and of themselves, but they can be used to help us follow agile principles. 

So make sure your stories tell a compelling story about the value to your customers. For the software you’re building, the story should focus on the who, what and why. 

There are three agile principles that we should keep in mind:

Working software is the primary measure of progress.

The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity, the art of maximizing the amount of work done is essential.

It’s worth it to spend time creating rich personas that help the team understand their various users and customers, their situations and their priorities. Any given user story might have multiple who’s sometimes your piece of functionality has more than one benefit for more than one customer or user. 

If working software is the primary measure of progress, we need to ensure we arrange and organize our work; we need to make sure that our work is organized and chunked into units that represent value to the customer. 

We need a way to sort out what is extremely valuable from what is less important. Some teams find that the ideal way to achieve these things is to visualize their work. So it’s easy to see what has been done, what is being done, and what is yet to be finished. 

Visualizing the state of various pieces of work can be done in software, or even on a wall with yellow sticky notes. But we want to concentrate just on how to represent the unit’s work. A good approach is to represent the work through simple stories that describe what the users world must look like, to mark a story as complete. 

Here are some examples of stories using a typical story template.

As a registered user, I want to change my password, so I can keep my account secure.

As a website visitor, I want to subscribe to the mailing list for a product. So I can get product updates through email.

As an admin user, I want to disable a user. So I can prevent unauthorized logins by past employees.

As a mobile app user, I want to save all my data to the cloud, so I can access it from another device.

There isn’t anything incredible about this particular format for stories, the examples we’ve just seen cover who what and why. Having a good template is a good way to capture key information to represent the idea of what the user needs, without getting bogged down in all the implementation details. 

When our development efforts are driven by stories that represent our understanding of user needs, it supports our principles and acceptable development practices.

What can we do to increase the quality of our stories will make the rest of our development process more efficient.

My next tip is that user stories just like traditional requirements need to focus on the what and not the how a good user story might be. 

As a frequent shopper, I want to purchase with one click so I can buy without hassle.

This story describes a goal without getting into the implementation details. 

A bad example is as a frequent shopper, 

I want the site to maintain a profile of demographic and payment data. So my one-click button purchases go faster. 

I’ve now told the developers exactly how to build it; it might not be the best way to provide that value. And my story doesn’t leave them any options.

 Many people learn a classic user story template, So that’s Why Well templates help remind us of the elements to include the who, what and why. 

Building an application the way the user thinks about value minimizes this risk. If you are following the other agile principles, the cost of some rework is trivial compared to the benefits it provides in delivering business value sooner rather than later.