Agile 101: A Practical Guide to User Story Creation

It is well-known that Agile practices stand out for their short-cycle, iterative, and adaptable approach to software development. One of the main features of Agile development methodology is its constant interaction between the stakeholders – development team, testing department, management and the customer. As a result, your customer is highly involved in the development process being able to influence the flow and direct software developers according to the business needs. Such an approach guarantees a fast development and predictable end result.

However, while interacting with each other during the development process, it is crucial not to forget the end user of your software. Your final goal, after all, is to provide the most valuable functionality for a particular set of customers – your target audience – people who will be using your software most often.

According to the 1995 Standish Group survey, understanding users’ needs is the most valuable aspect of a successful software development project. And the lack of user involvement is the second major reason why software development projects become unsuccessful and canceled. Even though this survey was conducted mostly among pioneers of Waterfall methods, it is also true for Agile methodology. You need to take into account needs of your end users.

This statement is supported by a Jim Johnson’s presentation where he argues that 45% of product features are never used by the target audience, 19% are rarely used, and only 36% of software functions are routinely used. How can this issue be addressed? One of the answers is Agile methodology user stories.

The term ‘user stories’ in Agile was coined in 1999 by Kent Beck, the early adept of Extreme Programming. It is a brief description of a function in software from the end user’s perspective. User stories in Agile are needed to create a vision of what features your users want to have, instead of what features you can provide to them.

In Agile project, a user story follows a simple template:

As a [type of user]

I want [to perform some task]

So that I can [achieve some goal/benefit].

Follow the 3C guidelines below to make sure your Agile methodology story brings value to the project:

1. Card. Use cards or sticky notes to write user stories explaining functions, which may be desired by the end users. Be creative and don’t hesitate to offer silly stories, as they may be later modified during brainstorm sessions.

2. Conversation. Elaborate suggestions on the cards through conversation to improve the user stories and filter out unnecessary features. Remember that discussion of the functions is more important than those cards, since it gives value to the stories.

3. Confirmation. Conduct acceptance tests and make sure user stories are delivered correctly.

Let’s take a look at a few examples of Agile methodology user stories.

User story title: Customer turns on TV remotely

As a TV user,

I want to turn on/off my TV set remotely

So that I don’t have to get off the couch.

Acceptance criterion 1:

• Given that the TV set is plugged in
• And remote control contains batteries
• And remote control is directed on the TV set within a reachable distance.
• When On/Off button is pressed on the remote control
• Then the remote control sends the signal to the TV set
• And the TV set switches on remotely.

Acceptance criterion 2:

• Given that the TV set is not plugged in
• Or remote control does not contain batteries
• Or remote control is not directed on the TV set within a reachable distance.
• When On/Off button is pressed on the remote control
• Then the remote control does not send the signal to the TV set
• And the TV set does not switch on remotely.

User story points in Agile methodology should be written at the beginning of the project, as soon as there is some kind of vision of the end goal of software. Usually, software managers hold a user story workshop where all of the stakeholders make suggestions about the required features of the software. The positive thing about these workshops is that the user stories are discussed right away between all of the project participants, including the customer. So there is a common understanding of the project by all parties. By the end of the workshop, there should be a product backlog which contains selected entries with a short narrative for each entry.

Epic user stories will definitely pop up during the brainstorming sessions in Agile methodology projects. Agile methodology epics are elaborated user stories which should be decomposed to brief user stories that fit into a single iteration. Epics should also be included in the product backlog for future work. As soon as you have a product backlog including an adequate amount of Agile user stories, proceed to the next development cycle. Remember that the backlog can be modified during the project, and any team member can offer suggestions.