Our Engineers can Write as well

How To Write Effective User Stories

From medieval age to mobile age, “satisfying users’’ and delivering “unparalleled experiences’’ to them have been the twin obsessions of businesses of all sizes. It has only grown in propositions over the years and is seeing heightened attention during these digital times where users are more informed, demanding and selective.

IT product companies are aware that anything that is not user centric may have to see the end of road sooner than expected. Thus, user experience and attractive user interfaces have gained traction to keep the users engaged with the applications that they use.

Among many processes involved to make this work in this blog, Future Focus will explore the role of “User stories “and how they can be the most popular agile technique to capture, map and design a software product’s requirements and features.

Hearing stories can be fun but telling effective stories can be tough. The same applies to user stories. So, what are User stories? Popular Wikipedia site says that a user story is an informal, natural language description of one or more features of a software system and are often written from the perspective of an end user or user of a system. Typically, they are recorded on index cards, on Post-it notes or in project management software.

Why are they important?

In simpler terms, they play a crucial role in designing software applications that deliver real value to its users.

How to go about it?

The person writing user stories should go beyond collecting, documenting the user requirements and perceive themselves as the users to have the right perspective of the application usage. Explore each story carefully as they are different and unique. Keep them simple, concise and easy to understand. Concentrate on the important aspect and leave the rest. The following template may help you write an effective user story.

User stories have a unique structure.

As a user, I should be able to do a certain thing with the application so that I can achieve what I want by using the application. If user stories were to be written for an application that was intended to provide transportation to employees of an organization,

As an employee, I should be able to request my organization’s human resource department to arrange a cab so that I can travel from my office to my client location to attend a scheduled meeting.

As an employee, I should be able to view my cab request so that I may know if my request has been approved or rejected by my manager and the human resource executive.

As an employee, I should be able to view the cab and driver details assigned to my request so that I will be able to board the right cab at the right time to reach my destination.

User stories are published by product managers along with acceptance criteria to guide the testing team in their testing effort.

It is to be noted that multiple acceptance criteria can be added for a single user story. They specify certain conditions which should be met by the application to obtain the desirable result which is serving the end users.

The user stories (along with acceptance criteria) are grouped to form the application’s features under development.

The below table is an example of a feature with user story and its acceptance criteria:

Feature: BOOK TRANSPORT

Story :

As an employee, I should be able to request my organization’s human resource department to arrange a cab so that I can travel from my office to my client location to attend a scheduled meeting.

Acceptance Criteria:

1. Employee should be able to request cab for

  • i. himself / herself
  • ii. include others who may be part of the travel.

2. He / she must be able to select the journey date and journey time.

3. He / she should be able to specify the starting point and drop point.

  • i. He / she should be able to pick starting and drop points from Google Maps.
  • ii. He / she should be able to type starting and drop points.
  • iii. He / she should be able to view matching addresses from Google Maps while typing the starting and drop points.

4. He / she should be able to input the purpose of journey that would be presented to their manager.

5. Once the cab request is created in the software system, a success message like “Your booking request is created successfully” should be displayed to the employee.

6. While requesting the cab, if employee misses any mandatory information, the field should be highlighted in red and employee should not be able to create the request.

Moving beyond these are the things that should be acknowledged while writing user stories:
  • It is mandatory to mention in each user story who the user is. There can be several types of users who may be using an application for distinct purposes. So, referring a user is very significant in user stories.

    Example:
    As an employee ….
    As a human resource executive …
    As a department’s manager …

  • User stories should not be very long as it may turn obscure for the development team when they implement it. Huge user stories may also lead to unnecessary ambiguities.

  • Technical stories should be avoided as user stories are written only from the end user’s perspective. User stories should never be written from the developer’s perspective or business owner’s perspective.

  • The ‘so that…’ part should always tell about the business value and not a technical requirement.

Basically, user stories should be broken down from epics and written as simple yet detailed stories. They can be further enhanced with wireframes, interactive designs and workflow diagrams to make the stories more appealing.

This is the flow of how an effective user story should be written.

  • Gather all the user requirements.

  • Write epics. Epics are big stories with top-notch description. It describes only the major functionalities and not the detailed ones.

  • Then, based on the epics, user stories should be written with detailed descriptions.

  • Multiple acceptance criteria can be added to the user stories.

  • At the end, it can also be enhanced by adding mockups, workflow diagrams, sketches, etc.

deepika - software engineer

Contributed by:

Deepika Chandru
Software Engineer

Your email address will not be published. Required fields are marked *