A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software 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.  The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team. User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

1. USER STORIES EXPLAINED
SCHOOL OF RPA

2. WHAT IS A USER STORY
• A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed
from the software 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.
• The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the
customer. Note that "customers" don't have to be external end users in the traditional sense, they can
also be internal customers or colleagues within your organization who depend on your team.
• User stories are a few sentences in simple language that outline the desired outcome. They don't go
into detail. Requirements are added later, once agreed upon by the team.

3. WHAT IS A USER STORY
• User stories are short, simple descriptions of a feature told from the perspective of the person who
desires the new capability, usually a user or customer of the system. They typically follow a simple
template:
• As a < type of user >, I want < some goal > so that < some reason >.
• User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls
or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about
features to discussing them. In fact, these discussions are more important than whatever text is written.

4. WHAT IS A USER STORY
• 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.
Thanks to 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 stories, and multiple epics comprise 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.

5. WHY CREATE USER STORIES?
• For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic)
into a series of steps and get on with it?
• But 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 user. A To Do list keeps the team focused on tasks that need 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 challenges and a small win, driving
momentum.

6. SOME USER STORY EXAMPLES
• One of the benefits of agile user stories is that they can be written at varying levels of detail. We can
write a user story to cover large amounts of functionality. These large user stories are generally known
as epics. Here is an epic agile user story example from a desktop backup product:
• As a user, I can backup my entire hard drive.
• As a power user, I can specify files or folders to backup based on file size, date created and date
modified.
• As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't
need saved.

7. LOOK HERE, AND YOU'LL SEE WHAT I MEAN:
As a/AN I want to... So that...
moderator
create a new game by entering a
name and an optional
description
I can start inviting estimators
moderator
invite estimators by giving them a
url where they can access the
game
we can start the game
estimator
join a game by entering my name
on the page I received the url for
I can participate
moderator
start a round by entering an item
in a single multi-line text field
we can estimate it
estimator see the item we're estimating
I know what I'm giving an
estimate for
estimator
see all items we will try to
estimate this session
I have a feel for the sizes of the
various

8. HOW IS DETAIL ADDED TO USER STORIES?
• Detail can be added to user stories in two ways:
• By splitting a user story into multiple, smaller user stories.
• By adding “conditions of satisfaction.”
• When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that
detail has been added. After all, more has been written.
• The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user
story is complete. Consider the following as another agile user story example:
• As a vice president of marketing, I want to select a holiday season to be used when reviewing the
performance of past advertising campaigns so that I can identify profitable ones.

9. CONSIDER THE FOLLOWING WHEN WRITING USER
STORIES:
• Definition of “Done” — The story is generally “done” when the user can complete the outlined task,
but make sure to define what that is.
• User personas — For Whom? If there are multiple end users, consider making multiple stories.
• Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it
complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be
met to confirm that the software is working as expected.

10. HOW IS DETAIL ADDED TO USER STORIES?
• Detail could be added to that user story example by adding the following conditions of satisfaction:
• Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s
Day, Labor Day, New Year’s Day.
• Support holidays that span two calendar years (none span three).
• Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
• Holiday seasons can be set to be a number of days prior to the holiday.

11. WHO WRITES USER STORIES?
• Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of
agile user stories exists, but that doesn’t mean that the product owner is the one who writes them.
Over the course of a good agile project, you should expect to have user story examples written by each
team member.Also, note that who writes a user story is far less important than who is involved in the
discussions of it.

12. WHEN ARE USER STORIES WRITTEN?
• User stories are written throughout the agile project. Usually a story-writing workshop is held near the
start of the agile project. Everyone on the team participates with the goal of creating a product backlog
that fully describes the functionality to be added over the course of the project or a three- to six-month
release cycle within it.
• Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller
stories that fit more readily into a single iteration. Additionally, new stories can be written and added to
the product backlog at any time and by anyone.

13. DO USER STORIES REPLACE A REQUIREMENTS DOCUMENT?
• Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be
developed in a product or service. Although product backlog items can be whatever the team desires, user
stories have emerged as the best and most popular form of product backlog items.
• While a product backlog can be thought of as a replacement for the requirements document of a traditional
project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is
incomplete until the discussions about that story occur.
• It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a
diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the
product owner or team desires.

14. USER STORYIES FROM EPIC

15. WANT TO LEARN BUSINESS ANALYSIS FROM US?
• CALL US ON :+91 900 480 9189
• Email: info@schoolofrpa.co.in
• Watch Videos on Our You Tube Channel
• https://www.youtube.com/channel/UCvPT
B1snZvxLr2XjSxE8BQg