User Stories:  

A user story is an informal, general explanation of a software

feature written from the perspective of the end user. Its purpose is to articulate how
a software feature will provide value to the customer.
It's tempting to think that user stories are, simply put, software system
requirements. But they're not. 
A key component of agile software development is putting people first, and a user
story puts end users at the center of the conversation. These stories use non-
technical 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 one of the core components of an agile program. They help
provide a user-focused framework for daily work — which drives collaboration,
creativity, and a better product overall.
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 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.
User Stories - INVEST
The acronym INVEST helps to remember a widely accepted set of criteria, or
checklist, to assess the quality of a user story. If the story fails to meet one of these
criteria, the team may want to reword it, or even consider a rewrite (which often
translates into physically tearing up the old story card and writing a new one).
A good user story should be - INVEST:
 Independent: Should be self-contained in a way that allows to be released
without depending on one another.
  Negotiable: Only capture the essence of user's need, leaving room for
conversation. User story should not be written like contract.
 Valuable: Delivers value to end user.
 Estimable: User stories have to able to be estimated so it can be properly
prioritized and fit into sprints.
 Small: A user story is a small chunk of work that allows it to be completed
in about 3 to 4 days.
 Testable: A user story has to be confirmed via pre-written acceptance
criteria.

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.
Learn more about epics and initiatives
Epics, stories, initiatives, themes these simple structures help agile teams
gracefully manage scope and structure work. Let’s say you and your team want to
do something ambitious, like launch a rocket into space. To do so, you’ll need to
structure your work: from the largest objectives down to the minute details. You’ll
want to be able to respond to change, report your progress, and stick to a plan.
Epics, stories, themes, and initiatives are precisely the tools you’ll need to do so.
By understanding how these popular agile methodologies help organize work, your
team can strike a healthy balance between structure, flexibility, and launching
rockets into space. What are stories, epics, initiatives, and themes? Stories, also
called “user stories,” are short requirements or requests written from the
perspective of an end user.
 Initiatives are collections of epics that drive toward a common goal.
 Epics are large bodies of work that can be broken down into a number of smaller
tasks (called stories).
 Themes are large focus areas that span the organization.
Agile Epic vs Story:
Stories and epics in agile are similar to stories and epics in film or literature. A
story is one simple narrative; a series of related and interdependent stories makes
up an epic. The same is true for your work management, where the completion of
related stories leads to the completion of an epic. The stories tell the arc of the
work completed while the epic shares a high-level view of the unifying objective.
On an agile team, stories are something the team can commit to finish within a one
or two-week sprint. Oftentimes, developers would work on dozens of stories a
month. Epics, in contrast, are few in number and take longer to complete. Teams
often have two or three epics they work to complete each quarter. If your company
was launching rockets into space, and wanted to improve the streaming service for
your launches, you might structure your stories like the ones below.
Examples of an agile story:
 iPhone users need access to a vertical view of the live feed when using the
mobile app.
 Desktop users need a “view full screen” button in the lower right hand
corner of the video player.
 Android users need to be linked to apple store.
  The above stories are all related, and could all be considered individual tasks
that drive toward the completion of a larger body of work (an epic). In this
case, the epic might be “Improve Streaming Service for Q1 Launch.”
 Organizing work into stories and epics also helps you and your team
communicates effectively within the organization. If you were reporting
your team’s progress to the Head of Engineering, you’d be speaking in
epics. If you were talking to a colleague on your development team, you’d
speak at the story level.
Agile Epic vs Initiative
In the same way that epics are made up of stories, initiatives are made up of epics.
Initiatives offer another level of organization above epics. In many cases, an
initiative compiles epics from multiple teams to achieve a much broader, bigger
goal than any of the epics themselves. While an epic is something you might
complete in a month or a quarter, initiatives are often completed in multiple
quarters to a year.
Initiatives vs. Themes
In many organizations the founders and management team will encourage the
pursuit of some aspirational destination. These are the (sometimes super corny)
goals announced each year or quarter, and themes are how you keep track of them.
 Initiatives are collections of epics
 Themes are labels that track high-level organizational goals
Initiatives have a structural design. They house epics, and the completion of those
epics will lead to the completion of the initiative. Themes are an organizational
tool that allows you to label backlog items, epics, and initiatives to understand
what work contributes to what organizational goals. Themes should inspire the
creation of epics and initiatives but don’t have a rigid 1-to-1 relationship with
them. A theme for a rocket ship company would be something like “Safety First.”
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.  

Working with user stories

Once a story has been written, it’s time to integrate it into your workflow.
Generally a story is written by the product owner, product manager, or program
manager and submitted for review.
During a sprint or iteration planning meeting, the team decides what stories they’ll
tackle that sprint. Teams now discuss the requirements and functionality that each
user story requires. This is an opportunity to get technical and creative in the
team’s implementation of the story. Once agreed upon, these requirements are
added to the story.
Another common step in this meeting is to score the stories based on their
complexity or time to completion. Teams use t-shirt sizes, the Fibonacci sequence,
or planning poker to make proper estimations. A story should be sized to complete
in one sprint, so as the team specs each story, they make sure to break up stories
that will go over that completion horizon.  
How to write user stories
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.
 
 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 your users and capture the problem or need in
their words. No need to guess at stories when you can source them from your
customers.
 
 Time — Time is a touchy subject. Many development teams avoid
discussions of time altogether, relying instead on their estimation frameworks.
Since stories should be compliable 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. Once the user stories are clearly defined, make sure they
are visible for the entire team.

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”
Breaking this down: 
 "As a [persona]": Who are we building this for? We’re not just after a job
title, we’re after the persona of the person. Max. Our team should have a shared
understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We
understand how that person works, how they think and what they feel. We have
empathy for Max.
 “Wants to”: Here we’re describing their intent — not the features they use.
What is it they’re actually trying to achieve? This statement should be
implementation free — if you’re describing any part of the UI and not what the
user goal is you're missing the point.
 “So that”: how does their immediate desire to do something this fit into their
bigger picture? What’s the overall benefit they’re trying to achieve? What is the
big problem that needs solving?
For example, user stories might look like:
 As Max, I want to invite my friends, so we can enjoy this service together.
 As Sascha, I want to organize my work, so I can feel more in control. 
 As a manager, I want to be able to understand my colleague’s progress, so I
can better report our success and failures. 
This structure is not required, but it is helpful for defining done. When that persona
can capture their desired value, then the story is complete. We encourage teams to
define their own structure, and then to stick to it.
Getting started with agile user stories
User stories describe the why and the what behind the day-to-day work of
development team members, often expressed as persona + need + purpose.
Understanding their role as the source of truth for what your team is delivering, but
also why, is key to a smooth process.
Start by evaluating the next, or most pressing, large project (e.g. an epic). Break it
down into smaller user stories, and work with the development team for
refinement. Once your stories are out in the wild where the whole team can see
them, you’re ready to get to work.
How to Write User Stories?
When getting started with writing user stories, a template can help ensure that
you don't inadvertently start writing technical tasks:
User Story Template
User stories only capture the essential elements of a requirement:
 Who it is for?
 What it expects from the system?
 Why it is important (optional?)?
Here is a simple format of user story used by 70% of practitioners:

Role - The user should be an actual human who interacts with the system.
 Be as specific as possible
 The development team is NOT a user
Action - The behavior of the system should be written as an action.
  Usually unique for each User Story
 The "system" is implied and does not get written in the story
 Active voice, not passive voice ("I can be notified")
Benefits - The benefit should be a real-world result that is non-functional or
external to the system.
 Many stories may share the same benefit statement.
 The benefit may be for other users or customers, not just for the user in the
story.
User Story Examples:
 As a [customer], I want [shopping cart feature] so that [I can easily
purchase items online].
 As an [manager], I want to [generate a report] so that [I can understand
which departments need more resources].
 As a [customer], I want to [receive an SMS when the item is arrived] so
that [I can go pick it up right away]
In the examples above:
 Role represents the person, system, subsystem or any entity else who will
interact with the system to be implemented to achieve a goal. He or she will
gain values by interacting with the system.
 Action represents a user's expectation that can be accomplished through
interacting with the system.
 Benefits represents the value behind the interaction with the system.
It is not a rule but a guideline that helps you think about a user story by considering
the followings:
 The user story will bring value to someone or certain party (e.g. customers).
 The user story is fulfilling a user's need (e.g. receive an SMS when the item
is arrived)
 There is a reason to support implementing this user story (e.g. customer can
go pick up the item she purchased)
Detailing User Stories with 3Cs (Card, Conversation and Confirmation)
Ron Jeffries, another of the creators of XP, described what has become our favorite
way to think about user stories. A User Story has three primary components, each
of which begin with the letter 'C': Card, Conversation, and Confirmation to
describe the three elements of a user story. Where:
Card
Card represents 2-3 sentences used to describe the intent of the story that can be
considered as an invitation to conversation. The card serves as a memorable token,
which summarizes intent and represents a more detailed requirement, whose details
remain to be determined.
You don't have to have all of the Product Backlog Items written out perfectly "up
front", before you bring them to the team. It acknowledges that the customer and
the team will be discovering the underlying business/system needed as they are
working on it. This discovery occurs through conversation and collaboration
around user stories. The Card is usually follows the format similar to the one
below:
As a (role) of the product, I can (do action) so that I can obtain (some benefits /
value)
Note:
 The written text, the invitation to a conversation, must address the "who
(role)", "what (action)" and "why (benefits)" of the story.

Conversation
Conversation represents a discussion between the target users, team, product
owner, and other stakeholders, which is necessary to determine the more detailed
behavior required to implement the intent. In other words, the card also represents
a "promise for a conversation" about the intent.
 The collaborative conversation facilitated by the Product Owner which
involves all stakeholders and the team.
 The conversation is where the real value of the story lies and the written
Card should be adjusted to reflect the current shared understanding of this
conversation.
  This conversation is mostly verbal but most often supported by
documentation and ideally automated tests of various sorts (e.g. Acceptance
Tests).

Confirmation
Confirmation represents the Acceptance Test, which is how the customer or
product owner will confirm that the story has been implemented to their
satisfaction. In other words, Confirmation represents the conditions of satisfaction
that will be applied to determine whether or not the story fulfills the intent as well
as the more detailed requirements.
 The Product Owner must confirm that the story is complete before it can be
considered "done"
 The team and the Product Owner check the "doneness" of each story in light
of the Team's current definition of "done"
 Specific acceptance criteria that is different from the current definition of
"done" can be established for individual stories, but the current criteria must
be well understood and agreed to by the Team. All associated acceptance
tests should be in a passing state.
How to Identify User Story?
User stories should be identified together with the stakeholders, preferably through
a face-to-face meeting. User story is a requirement discovery process instead of an
upfront requirement analysis process.
In the traditional requirements capturing approaches, system analyst tries to
understand customers' needs and then prepare a requirement specification for the
system in detail. This is not how the user story approach works. Instead of a
documentation process, the identification of user story is more like a note taking
process. We list the major steps for identifying user stories as following:
1. Through the discussions with users, we listen to and understand their
problems and needs
2. And then, write down their needs as user stories at the same time.
3. These user stories will become the source of requirements.
4. The details could be subsequently filled just-in-time, providing the team
with a "just-enough" requirement references throughout the project
development process.
Lifecycle of a User Story
In a broad sense, there are six main states for each user story throughout a software
project:
Pending
Through the communication between user and project team, user stories are found.
At this state, the user stories have nothing more than a short description of user's
need. There is no detailed discussion of requirements, no system logic and no
screen design yet. In fact, the only purpose of user story, for now, is just for
reminding all parties for a future discussion of user's request written in this user
story (card). It is possible that the user story will be discarded in the future.
To-do
Through a discussion between different stakeholders, the user stories to be
addressed in the next few weeks are decided, and are put into a time-box called a
sprint. Such user stories are said to be in the to-do state. No detailed discussion has
yet been carried out in this state.
Discussing
When a user story is in the Discussing state, the end user will communicate to the
development team in confirming the requirements as well as to define the
acceptance criteria. Development team will write down the requirements or any
decisions as conversation notes. UX specialist may create wireframes or
storyboards to let user preview the proposed features in visual mock-ups, and to
feel it. This process is known as user experience design (UX design).
Developing
After the requirements are clarified, the development team will design and
implement the features to fulfill user's requests.
Confirming
Upon the development team has implemented a user story, the user story will be
confirmed by the end user. He/she will be given access to the testing environment
or a semi-complete software product (sometimes known as an alpha version) for
confirming the feature. Confirmation will be performed based on the confirmation
items written when detailing the user story. Until the confirmation is done, the user
story is said to be in the Confirming state.
Finished
Finally, the feature is confirmed to be done, the user story is considered in the
Finished state. Typically, this is the end of the user story. If user has a new
requirement, either it is about a new feature, or it is an enhancement of the finished
user story, the team would create a new user story for the next iteration.
Organizing User Stories with Story Map
User stories is a useful way to build a better product backlog, one that is user-
centric and describes software requirements in a practical, actionable way. But user
stories on their own do not reveal the whole picture that can clue you in on the
larger journey the user goes through from the moment that load an app until they
reach their final goal.
A user story map can help us to arrange user stories into a manageable model for
plan, understand and organize the functionality of the system systematically. By
manipulating the structure of the map, we can identify holes and omissions in your
backlog and interrelating the user stories in a meaning structure; helping plan
holistic releases effectively that deliver value to users and business with each
release. User story map allows you to add a second dimension to your backlog.
Here are a few reasons you should consider using this technique:
 It allows you to see the big picture in your backlog.
 It gives you a better tool for making decisions about grooming and
prioritizing your backlog.
 It promotes silent brainstorming and a collaborative approach to generating
your user stories.
 It encourages an iterative development approach where your early deliveries
validate your architecture and solution.
 It is a great visual alternative to traditional project plans.
 It is a useful model for discussing and managing scope.
  Allows you to visualize dimensional planning and real options for your
project/product.
User Story Map Template
Story mapping is a top-down approach of requirement gathering and is represented
as a tree. Story mapping starts from user activities. A user activity should achieved
a particular goals. And to complete an activity, users needs to perform the
associated tasks. And these tasks can be transformed into epics and user stories for
software development. Typically, user story map consists of 3 levels: User
Activities / User Tasks / User Stories. For enterprise scale projects, perhaps a 4
levels structure may be more appropriate by introduce Epics in the third level.
User Activities - They are laid out in the second column. This are major objectives
that the system must support, with tangible business outcome. The entire row
forms the backbone.
User Tasks - Each of the user activities is broke down into a set of related user
tasks called narrative flow. The entire row forms the walking skeleton)
Epics / user stories - Each of the user tasks is broken down into Epics / User
Stories underneath directly the user task that the feature realizes. Depending on the
complexity of your projects, your team may choose the 3 or 4 level of story map
which is more appropriate to you as mentioned above.
Visual Paradigm Story Map supports both 3 and 4 levels of complexity for you
to cope wide variety type of projects.
3 Level Story Map (User Activates > User Tasks > User Stories)

4 Level Story Map (User Activates > User Tasks > Epics > User Stories)
Planning for Releases
Use a separator to identify slices of tasks that users might use your software for to
reach their goals. The smallest number of tasks that allow your specific target users
to reach their goal compose a viable product release as shown in the Figure below:

If you want to develop a story map like this one, please check Visual
Paradigm's story mapping tool.
How to Use User Story Effectively?
Just like many other software development methodologies, if you apply user story
properly in your software project you will be able to produce a quality software
system plus to win the trust and satisfaction from customers. Here are some points
that you need to keep in mind when using user story:
 Keep the description of user story short.
 Think from end user's point of view when writing a user story.
 Confirmation items must be defined before you start the development
 Estimate the user story before implementation to ensure the workload of
your team is under control.
 Requirements are found with the end users, not by the end user or just by the
development team. Keeping a good relationship with the end users will be a
win-win situation for both parties.
 Communication is always important in understanding what the end user
wants.