How to write a good user story.

Tell a story and get work done. 

When you are working as a scrum master or agile coach, your biggest challenge is getting others to understand the concepts of agile.  It is like teaching young children to read.  The concepts seem natural to an adult, but to a six-year-old, it is an alien skill to master.  It occurred to me this week I have written numerous blogs about the different aspects of agile development, but I have never written a blog about authoring user stories.  Today, I want to change that oversight.

Let me begin by saying I am sharing with you how I teach others to write stories.  Each coach and each environment is different.  Feel free to treat this blog as an informed suggestion of how you can do things at your organization.

In the early days of agile, a user story could fit on a post-it note.  Team members would see the story ask the product owner for some discussion about what to do and then the work would get done.  The early approach assumed the development team was in the same room and the product owner was always available to answer questions.  Today with team members scattered around the globe, product owners focusing on customers, and countless tools to track work items, it is not realistic to rely on just post-it notes.  Regardless of what system you use to track user stories, the first thing you should do is boil the work down to one sentence.  I use the following format.

As X I want/Need Y because of Z.

The template is easy to follow and works in most situations.  Here are two examples.

Example #1 – As a sales manager I want the background of the shopping cart page to be blue because it reduces the number of dropped shopping carts.

Example #2 – As a user, I would like the website to save my customer information because I do not want to retype information. 

In both examples, the subject of the sentence is the person who needs the work done.  The predicate of the sentence is the actual work.  The modifying clause is a credible reason why the work needs to get done.  The sentence should satisfy the Who, What, Where and Why of the work.  It is up to the developers to provide a credible answer to When the work gets done.

Once you have authored a user story, it needs acceptance criteria.  Acceptance criteria are important because it removes misunderstanding between a member of the development team and the product owner.  Unlike waterfall techniques which demand long and confusing narratives, I show product owners the Gherkin or Given, When, Then (GWT) formatting of writing acceptance criteria.

Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

Notice the GWT does not say how to do the work; it just says what the product owner expects the development team to deliver.  The team could use session variables, cache objects, or cookies to do the work.  It does not matter.

A user story should look like this in the work item tracking system.

23 – Save shipping and billing info
As a user, I would like the website to save my customer information because I do not want to retype information.
23.01 
Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

The number is usually automatically generated by the item tracking system.  I use a ##.0# numbering system for acceptance criteria for clarity, and I provide a title for stories.  During stand-up meetings, developers refer to stories by saying, “I am working on number 23 save shipping and billing info.”

I hope this is a good starting point for how to write user stories.  With practice, it will become natural just like reading.

Until next time.