It’s the product owner’s responsibility to make sure a product backlog of agile user stories exists, but the product owner is not the one who writes them. Over the course of a good agile project, one should expect to have user story examples written by every team member.

1.What are agile user stories?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the end user’s perspective. A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer. Its purpose is to articulate how a software feature will provide value to the customer. A key component of agile software development is putting people first, and a user story puts end users at the centre of the conversation. These stories use non-technical, simple English language to provide context for the development team and their efforts. After reading a user story, the team knows why they are building, what they’re building, and what value it creates. 

User stories are a few sentences in simple English language that outline the desired outcome. They don’t go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Because of stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

User stories are also the building blocks of larger agile frameworks like Epics and initiatives. Epics are large work items broken down into a set of user stories, and multiple epics constitute an Initiative. These larger structures ensure that the day to day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.

2. Why create user stories?

For development teams new to agile, user stories are used to break the big project (the epic) into a series of steps and get on with it. User stories give the team important context and associate tasks with the value those tasks bring.

User stories serve a number of key benefits:

• Stories keep the focus on the end user. 

A To Do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
 

• Stories enable collaboration. 

With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.

• Stories drive creative solutions. 

Stories encourage the team to think critically and creatively about how to best solve for an end goal.
 

• Stories create momentum. 

With each passing story the development team enjoys a small challenge and a small win, driving momentum.  

3. How to write user stories

User stories can be written by considering the following points:

• Definition of “Done”- The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
   
• Outline subtasks or tasks – Decide which specific steps need to be completed and who is responsible for each of them.
   
• User personas- For Whom? If there are multiple end users, consider making multiple stories.
   
• Ordered Steps – Write a story for each step in a larger process.
   
• Listen to feedback – Talk to the end users and capture the problem or need in their words. No need to guess at stories when one can source them from the customers.
   
• Time- Time is of essence. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completed in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.

4. User Story Sample

Step 1: IDENTIFY the 3 Steps:

A user story typically has three main components: the user, an action, and some promised value. This breakdown allows for easy digestion of the issue at hand. The user in our example would be the account holder as they are the ones interacting with the system. Next, there are two distinct user actions that can be performed. These are log On and searching. Finally, by combining the first two components and adding value propositions, the following independent user stories can be created:

1. As an account holder, I want to log on to my account so that I can view my account information
2. As an account holder, I want to search my account information so that I can know my account’s balance
3. As an account holder, I want to search my account information so that I can know my transaction details
4. As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

 Step 2: VALIDATE with Acceptance Criteria

It is fine now that the three components have been incorporated to create small, independent stories. But these stories cannot be accepted as complete until certain conditions are met. These conditions, known as acceptance criteria, are needed to act as the basis against which the user story is to be validated and tested.

Taking a look at the first and last stories, acceptance criteria for these can be readily derived from the base requirement.

User Story 1: Description

As an account holder, I want to log on to my account so that I can view my account information.

Acceptance Criteria

1. Verify that account profile is returned
2. Verify that user can log on multiple times

 User Story 2: Description

As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

Acceptance Criteria

1. Verify that full details on the transaction (Date, Transaction Description, Transaction amount) are returned
2. Verify that search can be done multiple times

 Step 3: Take care of Non-Functional Requirements(NFR) as well

It’s a common practice for acceptance criteria to be made up solely of the functional requirements of the system. But the non-functional aspects need to be taken care of as well. System attributes such as performance, usability, scalability are critical to the accurate development of an application feature. Looking at our base requirement, performance criteria can be added to our stories to account for responsiveness and speed of searches. Also, security criteria can be added to account for user validation.

User Story 1: Description

As an account holder, I want to log on and view my account information.

Acceptance Criteria

1. Verify that account profile is returned
2. Verify that user can enter username and password
3. Verify that user can log on multiple times
4. Verify that account is locked after three (3) failed login attempts. ← Security NFR
5. Verify that profile and account info is loaded in 10 seconds. ← Performance NFR

User Story 2: Description

As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

Acceptance Criteria

1. Verify that full details on the transaction (Date, Transaction Description, Transaction amount) are returned
2. Verify that if a large set of results are returned, a page view is presented with page numbers and ‘Prev’, ‘Next’ links
3. Verify that all monetary amounts are accurate to two decimal places. ← Integrity NFR
4. Verify that transaction details are returned in 10 seconds. ←  Performance NFR

5. User Story Checklist

✅	Keep them short.
✅	Keep them simple.
✅	Write from the perspective of the end user.
✅	Make the benefit of the story clear-what is the reason for the story?.
✅	Describe one piece of functionality, if you have to write. Break it into 2 stories.
✅	Team work is important in writing stories.
✅	Use acceptance criteria to show a MVP.

6. Acceptance Criteria Should Include

✅	Negative scenarios of the functionality.
✅	Functional and Non-Functional use cases.
✅	Performance concerns and guidelines.
✅	Goal of System and feature.
✅	End User flow.
✅	Impact of user story on other features.
✅	UX concerns, if any.

7. Acceptance Criteria Should Not Include

❌	Code review was done.
❌	Major issues.
❌	Performance testing performed.
❌	Acceptance and functional testing done.