Writing a Good User Story

In the past few articles we have covered many different topics about Scrum and have used the term “User Story” multiple times. If you are someone who is already working in an agile environment you should be quite familiar with the term “User Story” and what it means. If you are someone newly taking up Agile software development you may not know what it is or how it is supposed to be used. The purpose of this article is to help you understand what a User Story is and how to Write a Good User Story.

As User Stories are the heart and soul of an Agile project, a badly conceived set of user stories could result in a product that doesn’t serve the purpose it was built to be.

What is a User Story?

A user story in Agile software development is used to capture a description of a software feature from an end user’s perspective. A User story is usually a short, simple description of the feature in a format like:

As XYZ Type User, I want to be able to do A, B and C so that We can achieve 1, 2, 3 benefits.  

Who Writes these User Stories?

Primarily it is the Product Owner who writes User Stories however there are no specific restrictions as such on who can create a user story. Anyone can write user stories however it is the product owners responsibility to make sure that the backlog of user stories is relevant and in the right priority order.

When are User Stories Written?

Unlike traditional waterfall projects where you start off with the finalized (or at least a baselined) version of the functional specs, Agile doesn’t expect a super well-defined backlog for the entire product feature set. Usually a story writing workshop happens prior to the start of the agile project with user stories being discussed & created for the next few Sprints. During the course of the project, more stories will continue to be created and will get added to the backlog for prioritization.

Of course, some of these initial user stories will be Epic Stories which are quite huge. The team (with the help & guidance of the product owner) will decompose these Epics into smaller stories that can be completed in a single Iteration or Sprint.

Tips to Writing a Good User Story

Let’s switch back to the key topic at hand – how to write a good user story. There are a few key tips to help you write a good story.

Tip 1: Keep the User Needs as Top Priority

As the title sounds a User Story is supposed to explain what a user wants and so the needs of the user should be kept as top priority. A user story is supposed to capture a specific product functionality or action that the user would do for ex: As Admin User I should be able to delete unwanted users from the system so that we can restrict access to the System to only “Current” staff.

If you don’t know who the user is or how they would use the product or what action they are going to perform, it would be better if you DON’T create the story because the primary objective is getting defeated.

Tip 2: Keep the Story Simple and Concise

As with any document, keeping it Simple and Concise is a No Brainer. Avoid using confusing or ambiguous terms in the user story. Focus on what is important and leave out the trivial or non-pertinent details.

Let’s look at the Example from Tip 1: As Admin User I should be able to delete unwanted users from the system so that we can restrict access to the System to only “Current” staff.

Is this a good example? If you are unsure, just scroll up to the beginning of the article about what is a User Story and compare this against the template.

Tip 3: Start with Epics

An Epic is a big User Story that doesn’t contain too many details. It often times describes a high level feature and requires a considerable amount of work in order to translate this into working product functionalities.

You may be wondering why should I start with Epics – right?

Starting with Epic stories allows you to chart out the product functionality skeleton without delving too much on details. This is especially helpful for new products because you may not have thought about all of the Nitty-gritties of the product during the initial stages. By setting the skeleton of the feature through the Epic, you are keeping yourself open to the details of the feature which can be altered based on the specific customer needs at that point in time. Typically these Epics get broken down into smaller pieces and then get scheduled during the course of the project.

Lets go back to the example from Tips 1 & 2 – They are very specific user stories but if you rewind the clock a few months back when the original product was being conceptualized, this feature would’ve been under an Epic that talked about Admin User Privileges. This Epic would’ve been reviewed by the team and broken down into smaller Admin User Actions like – Deleting unwanted users, Adding new Users, Editing User Permissions etc.

Now, get the picture?

Tip 4: Collaborate with the Team until the Stories are Refined and Ready

Breaking down an Epic into a smaller user story is not an activity that is supposed to be done by the Product Owner all by himself. It is supposed to be a collaborative activity where the scrum team pitches in with ideas & suggestions until the epic is broken down into multiple smaller, detailed user stories that are:

-        Clear

-        Ready

-        Feasible and

-        Testable

All Scrum team members should have a common understanding of the story’s meaning and purpose. Also, the story shouldn’t be too big and should comfortably fit into one Sprint. More importantly there must be an effective way to determine if the story is “Done”.

Tip 5: Add Acceptance Criteria

One of the strongly recommended suggestions while creating user stories is the addition of the Acceptance Criteria. Some agile practitioners refer to this as the Definition of Done but the intent is the same. An acceptance criteria or definition of done basically describes the conditions that have to be fulfilled so that the story can be marked as “Done”. This criteria makes the story testable and also ensures that the story can be demoed or released to the users.

Even the Simplest user story must have at least one Acceptance Criteria. As the complexity level goes up, the number of Acceptance conditions may go up but remember to add them for all your stories.