UNIT – 7

USER STORIES

What are 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. 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.

Why User Story ?

In agile software development, user stories help articulate what value a product feature can
bring and have a better understanding of why users want a certain functionality. It helps the
product manager and development team shift their focus from writing about the software
features to discussing the features.

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 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.

Characteristics of a User Story

 Be complete enough to demonstrate user value.

 Be user-centric.
 Start with an epic.
 Be short, simple, and clear.
 Contain supporting files and documentation if necessary.
  Be comprehensive enough to demonstrate value, but simple enough to develop in a single
iteration.

How to write / Create 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
completable 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.

3C’s in User Stories

Once the user stories are clearly defined, make sure they are visible for the entire team.

The 3 C’s of User Stories help to keep the purpose of the user story in perspective.

 The first C is the user story in its raw form, the Card. User stories are manually written
on index “cards” to keep them concise. The standard format has 3 basic components: As
a [user type], I want / need [goal] so that I can accomplish [justification/business value].
The Card is a just a place holder.
 The second C is the Conversation. The Conversation is necessary to get further details
about the Card. The conversation promotes the incremental and continuous
collaboration among the agile team needed to build a shared understanding around the
problem and potential solution.
  The third C is the Confirmation. Confirmation is the acceptance criteria which captures
the essential requirements and translates them into the test criteria so that we know

when we’ve successfully delivered the user story.

Life Cycle of a User Story

User Story Mapping

User story mapping is a visual exercise that helps product managers and their development
teams define the work that will create the most delightful user experience. It is used to improve
teams’ understanding of their customers and to prioritize work.

In user story mapping, teams create a dynamic outline of a representative user’s interactions
with the product, evaluate which steps have the most benefit for the user, and prioritize what
should be built next. For agile organizations, it provides an alternative to building a flat list of
backlog items or working from lengthy requirements documents.

User story mapping employs the concept of user stories — which communicate requirements
from the perspective of user value — to validate and build shared understanding of the steps to
create a product users love. Teams write user stories in a format that captures business value
and can be completed within a development iteration (usually called a sprint).

The user story format — As a [type of user], I want to [action] so that [benefit]. — can be
helpful in thinking about product interactions from a user’s perspective.

Estimation
User Story Point
Story points are units of measure for expressing an estimate of the overall effort required to
fully implement a product backlog item or any other piece of work. Teams assign story points
relative to work complexity, the amount of work, and risk or uncertainty.

Story point estimation is a technique used in Agile project management to replace task
estimation in time or money. The smallest tasks are estimated at 1 point and then other tasks
are weighed and estimated in accordance with that task.

Components of Story Point Estimation

 Risk: The risk of a particular project or item includes vague demands, dependence on a
third party, or changes mid-task.
 Complexity: This component is determined by how difficult the feature is to develop.

Steps Involved in Estimation

 Step 1: Establish estimate scope and purpose

Define and document expectations. When all participants understand the scope and
purpose of the estimate, you clear up contradictory assumptions, establish a baseline for
measuring the effect of future changes, and head off potential misunderstandings.
 Step 2: Establish technical baseline, ground rules, and assumptions
Identify the functionality included in the estimate. If detailed functionality is not known,
document ground rules and assumptions, and what is and isn’t included in the estimate.
 Issues of Commercial Off-the-Shelf (COTS), reuse, and other assumptions should be
documented as well.
 Step 3: Collect data
Identify the data required and the information holders. Provide participants with
questions and clear definitions beforehand. During interview confirm data is realistic and
valid. Build and refer to repositories of project histories. Be sure to capture uncertainty.
 Step 4: Determine size and scope
If circumstances force you to compromise on your estimating methodology, spend the
bulk of the time you have on sizing the project (the use of sizing databases and tools can
facilitate this process). This is arguably the most critical step in determining the ultimate
success of a project. Sizing and scoping drives every aspect of the project, constrains the
actions that can be taken in the development or upgrade of a product, and limits available
options.
 Step 5: Prepare baseline estimate
Estimating a project should not be thought of as a one-time activity. As projects progress,
unknowns become knowns, and new and unexpected issues and opportunities arise. Life
happens. Refreshing estimates and documenting estimate deltas throughout the
development process ensures that 1) the evaluation of trade-offs is based on increasingly
reliable data, 2) the organization has a “most accurate” estimate at any given point in
time, and 3) estimation accuracy improves over time.
 Step 6: Quantify risks and risk analysis
Risk can be characterized in terms of a loss of time, quality, money, control, or
understanding. The loss associated with a risk is called the risk impact. Risk cannot be
eliminated, but it can be planned for. Risk, by itself, will not threaten the success of a
project if it is recognized and addressed in a timely fashion.
 Step 7: Validate and review
Validating and reviewing your estimate provides a systematic confirmation of your
estimate’s integrity. This step enables the organization to be more proactive in adjusting
project variables, and justifies confidence that project data is sound, methods are
effective, anticipated results are accurate, and focus is properly directed.
 Step 8: Generate a project plan
Generating a project plan employs the project estimate as a basis for allocating and
communicating specific cost, resources, and timelines in a detailed function and task-
oriented work breakdown structure.
 Step 9: Document estimate and lessons learned
Each time you complete or update an estimate and upon completion of a project, you
should document the information that proved pertinent and record lessons learned. By
doing so, you document a “best effort” process, capture actual results with which to
calibrate your estimation models.
 Step 10: Track performance (measurement and feedback)
In-process information should be collected continuously and compared against the
original plan and baseline. If performance varies consistently or significantly, corrective
options should be evaluated and implemented to get the project back on track.
Performance feedback should also be reviewed and project data retained to refine the
estimating process, itself.