Agile User Stories

User stories are obviously a part of an agile approach that helps you to shift your focus from writing about some requirements to talking about these requirements. All agile user stories comprise a written sentence or two and, the most important thing, a series of conversations about the functionality that you want.

What is a user story?

Agile user stories are normally short, with simple descriptions of a feature which are told from the point of view of the person who want the new capability, normally a customer or user of the system. User stories have their specific format:

“As a,

I want to,

So that I can”

Agile user stories are frequently written on sticky notes or index cards, and placed in a shoe box, and these boxes are normally arranged on tables or walls which help them to ease planning and discussion about it. As such, they completely shift their focus from writing about these features to discussing them. Of course, these discussions are very important than the texts that are written.

Example of a user story

One of the advantages of agile user stories is that these stories can be written easily at varying levels of detail. Anyone can write an agile user story to include many functionalities. These detailed agile user stories are basically known as epics. Here, I am including an epic agile user story example, which is taken from a desktop backup product:

· As a user, I can do back up my entire hard drive.

As, an epic is normally too large for an agile team to finish it in one emphasis, it is broken up into various smaller user stories before it is worked on. Same in this case, the epic mentioned above can be split into dozens user stories (or possibly hundreds), plus the twos I am including below:

· As an experienced user, I can identify files or folders to build a backup which can be based on file size, folder size, date modified and date created.

· As a user, I can specify folders not to back up because of which my backup drive isn't normally filled up with files and folders that I don't need to be saved.

How do you organize stories?

Epic user stories are used to describe a user action and the child stories describe that action in detail. Test cases and sticky notes are a place to add some further points and details to discuss something which can be relative to some individual stories. In fact, both types of stories have the same format.

Another thing, there is a school of thought about that the epics are big stories, and they surely sound big. My wide advice is that to keep these epic stories relatively small. As. I have done a lot of practice on story writing workshops and most of the first-time child stories that I see are in fact what I would start with as epic stories. What is the reason of it? Well, as you know, operating and developing a software is expensive.

You may as well have some good narrative coverage with different stories about anything and you are building to drive some good discussions about these stories and want to discuss what will be most important and valuable to a user and how you will test it. 

Let’s look at an example. Focusing to the narrative of an HR manager who is willing to create a screening quiz among the users for a new job description, he should start with this epic:

“As the HR manager, I want to make a screening quiz among all the participants so that I can make sure I have prepared to use it when I am going to interview job candidates.”

The child stories and their test cases them to decompose that epic story into more detailed steps.

Anyone can write agile user stories. It is the responsibility of the owner of the product, to make sure that a thing backlog of agile user stories exists, but it never ever means that the product owner is the one who writes user stories.

Final thoughts

· User stories are supposed to take as a centerpiece for frequent discussion.

· In case, if you are not familiar with agile, I recommend you find an article related to agile and read that again.