Writing Effective User Stories the Agile Way !!

In the world of agile, the most commonly used term is the ‘user story‘. So, what is this user story, how is this different from traditional requirements elicitation process and what are the best practices in writing these user stories….This blog is a step towards answering all these questions.

In the traditional waterfall methodology, a requirements document was written that detailed on what the software should do, included technical as well as non-technical aspects. While on the other hand, a ‘user story‘ is non-technical software need that is written from the end user’s perspective. To make it simple, in an iterative agile methodology, the requirements are broken down in the form of user stories – small, independent, testable and valuable asset to the customer. 

It is very important that product teams are empowered to write effective user stories and they follow a consistent pattern. The above user story template is recommended to be used by business analysts which is then shared with product teams. Various tools can be used to document these user stories like Atlassian Jira, IBM Rational Team Concert (RTC), Microsoft Team Foundation Server (TFS), VersionOne, Rally, etc. This template is explicitly mentions on three important aspects-

a. “who is performing the role”, like “As an admin…”

b. “what is to performed”, like “I want to auto-run an environment build” 

c. “mention benefits”, like “so that I can save time in building environments” 

Lets take a look at some more examples….

Example 1:

Consider a user logging into a shopping web application would like to view all previous transactions that have been performed. 

Example 2:

Consider an Infra admin needs to upgrade a SharePoint software to its latest version ‘x’ and this has to be documented as a user story.

Example 3:

Consider that you are an automation lead and have been given a task to configure Jenkins to auto-configure email notifications. 

Hope the above examples will serve as good cheat sheets for your teams. These examples show ineffective ways as well as effective ways of writing user stories. Typically, you will find user stories are written in hurry or may be the team isn’t aware of the template and they become inconsistent. We should mentor such teams and encourage them to write effective user stories. A user story should clearly illustrate the role, the action and the benefits. This way it becomes crisp and worthy.

Based on these user stories, acceptance criteria and definition of done are also written. Hence, it becomes important to articulate the user stories in the right agile way !! 

Do look forward for more articles on acceptance criteria and definition of done 🙂