CHAPTER 8

USER STORY
Syllabus
What are user stories? Why user story? Basic concepts; Characteristics; How to write/create
user stories? Steps; 3C’s in user stories; Life cycle of user story. User story map.

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.
 User stories are not about documenting requirements. They want to enable developer
to move fast and develop software as quickly as possible - not to impose any
overhead.
 In software development and product management, a user story is an informal, natural
language description of one or more features of a software system.
 A user story is a tool used in Agile software development to capture a description of a
software feature from an end-user perspective.
 A user story describes the type of user, what they want and why.
 A user story helps to create a simplified description of a requirement.
 User stories are often recorded on index cards, on post-it notes, or in project
management software.
 Depending on the project, user stories may be written by various stakeholders such as
clients, users, managers or development team members.
 User stories are part of an agile approach that helps shift the focus from writing about
requirements to talking about them.
 All agile user stories include a written sentence or two and, more importantly, a series
of conversations about the desired functionality.

Reasons for User Story

 A user story helps to create a simplified description of a requirement.
 The purpose of a user story is to write down how a project will deliver value back to
the end user.
 It is then the development team's job to take care of how to develop the code that will
satisfy the requirements of the user story.

Benefits of User Story

1. Stories keep the focus on the 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.
2. 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.
3. Stories drive creative solutions
 Stories encourage the team to think critically and creatively about how to best solve
for an end goal.
4. Stories create momentum
With each passing story, the development team enjoys a small challenge and a small
win, driving momentum.
Basic Concepts of User Story
 A user story is a lightweight method for quickly capturing the "who", "what" and
"why" of a product requirement.
 In simple terms, user stories are stated ideas of requirements that express what users
need.
 User stories are brief, with each element often containing fewer than 10 or 15 words
each.
 User stories are "to-do" lists that help you determine the steps along the project's path.
 They help ensure that your process, as well as the resulting product, will meet user’s
requirements.
Characteristics of User Story
1. Be complete enough to demonstrate user value.
2. Be user-centric.
3. Start with an epic.
4. Be short, simple, and clear.
5. Contain supporting files and documentation if necessary.
6. Be comprehensive enough to demonstrate value, but simple enough to develop in a
single iteration.
7. Be written based on the input of all stakeholders.
8. Be flexible and negotiable without impacting other stories or features.
9. Be easy to test.
10. Include acceptance criteria (conditions of satisfaction) for testers.

Steps to Write/Create User Stories

1. Users Come First
 As its name suggests, a user story describes how a customer or user employs
the product; it is told from the user’s perspective.
 What’s more, user stories are particularly helpful to capture a specific
functionality, such as, searching for a product or making a booking.

 The picture illustrates the relationship between the user, the story, and the
product functionality, symbolised by the circle.
  If developer don’t know who the users and customers are and why they would
want to use the product, then developer should not write any user stories.
 Carry out the necessary user research first
 Example, by observing and interviewing users.
2. Use Personas to Discover the Right Stories
 A great technique to capture the insights about the users and customers is
working with personas.

 Personas are fictional characters that are based on first-hand knowledge of the
target group.
 They usually consist of a name and a picture; relevant characteristics,
behaviours, and attitudes; and a goal.
 The goal is the benefit the persona wants to achieve, or the problem the
character wants to see solved by using the product.
 But there is more to it: The personal goals help developer to discover the right
stories.
3. Create Stories Collaboratively
 User stories are intended as a lightweight technique that allows developer to
move fast.
 They are not a specification, but a collaboration tool.

 Stories should never be handed off to a development team.

 Instead, they should be embedded in a conversation: The product owner and
the team should discuss the stories together.
 This allows developer to capture only the minimum amount of information,
reduce overhead, and accelerate delivery.
4. Keep the Stories Simple and Concise
 Write the stories so that they are easy to understand.
 Keep them simple and concise.
 Avoid confusing and ambiguous terms, and use active voice.
 Focus on what’s important, and leave out the rest.
5. Start with Epics
 An epic is a big, sketchy, coarse-grained story.
 It is typically broken into several user stories over time - leveraging the user
feedback on early prototypes and product increments.
  Developer can think of it as a headline and a placeholder for more detailed
stories.
 Starting with epics allows developer to sketch the product functionality
without committing to the details.
 This is particularly helpful for describing new products and features: It allows
user to capture the rough scope, and it buys developer time to learn more
about how to best address the needs of the users.
 It also reduces the time and effort required to integrate new insights.
6. Refine the Stories until They are Ready
 Break the epics into smaller, detailed stories until they are ready: clear,
feasible, and testable.

 All development team members should have a shared understanding of the

story’s meaning; the story should not be too big and comfortably fit into a
sprint; and there has to be an effective way to determine if the story is done.
7. Add Acceptance Criteria
 As we break epics into smaller stories, remember to add acceptance criteria.
 Acceptance criteria complement the narrative.
 They allow developer to describe the conditions that have to be fulfilled so
that the story is done.
 The criteria enrich the story, they make it testable, and they ensure that the
story can be demoed or released to the users and other stakeholders.
8. Use (Paper) Cards
 User stories emerged in Extreme Programming (XP), and the early XP
literature talks about story cards rather than user stories.
 There is a simple reason: User stories used to be captured on paper cards.
 This approach provides three benefits:
a. Paper cards are cheap and easy to use.
b. They facilitate collaboration: Everyone can take a card and jot down an
idea.
c. Cards can be easily grouped on the table or wall to check for consistency
and completeness and to visualise dependencies. If using paper cards is not
an option for developer, then choose a tool that allows developer to create
virtual cards, as Trello does, for ex.
9. Keep the Stories Visible and Accessible
 Stories want to communicate information.
 Therefore, don’t hide them on a network drive, the corporate intranet jungle,
or a licensed tool. Make them visible, for instance, by putting them up on the
wall.
3C’s in 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.
1. 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.
 Developer don't have to have all of the Product Backlog Items written out
perfectly "up front", before developer 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 following 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)
2. Conversation
 Conversation represents a discussion between the target users, team, product
owner, and other stakeholders, which is necessary to determine the more
detailed behaviour 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.
 Example: Acceptance Tests
3. 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 fulfils 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.
Life Cycle of User Story
There are six main states for each user story throughout a software project as,
a. Pending
b. To-do
c. Discussing
d. Developing
e. Confirming
f. Finished
1. 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.
2. 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.
3. 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).
4. Developing
After the requirements are clarified, the development team will design and implement
the features to fulfil user's requests.
5. 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.
6. 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.
User Story Map
 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 the
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 us to add a second dimension to the backlog.
 Reasons to be considered using this technique,
a. It allows developer to see the big picture in the backlog.
b. It gives developer a better tool for making decisions about grooming and
prioritizing the backlog.
c. It promotes silent brainstorming and a collaborative approach to generating the
user stories.
d. It encourages an iterative development approach where developer early deliveries
validate the architecture and solution.
e. It is a great visual alternative to traditional project plans.
f. It is a useful model for discussing and managing scope.
g. Allows developer to visualize dimensional planning and real options for the
project/product.

QUESTIONS
1. Define User Story, User Story Map
2. List the benefits of user story.
3. List the characteristics of user story.
4. Explain the steps to create/write user stories.
5. Describe 3 C’s in User Story.
6. Explain the user story life cycle.
7. List the reasons to consider the user story map.
8. Write the User Stories for the Given Problem Statement.