Dr Sumaira Khan

User Stories-
Requirement
Gathering in Agile
▶ User stories are value-focused units of
delivery that are typically used in Agile
projects.
▶ Written from the customer or stakeholder’s
Perspective, user stories share what is
needed and why.
WHO
WHAT
WHY
Who
?
▶ The “who” in a user story is typically someone
with a particular role or title or it could be
from the perspective of a persona a fictitious,
sample user’s behaviors and needs, spelled out
in detail.
▶ Avoid being too general (e.g. “As a user...”) as
it defeats the purpose of pinpointing the value
for your target audience.
▶ Write all stories with the “who” included, even
those stories that are very technical.
What?
▶ The “what” in a user story specifies
the need, feature, or functionality
that is desired by the “who” or
services to be implemented into the
system.

▶ This is what the team will build into

the software or service.
Why?
▶ Specifies the value, keeping the
needs of users and customers front
and center.
▶ Value based delivery- why the story
should be delivered.
▶ If you can’t write a user story with
the “why” included, then maybe it’s
not needed.
▶Examples:
▶ Log in to my web
energy-monitoring
portal.
▶ See my daily energy
usage.
▶ Check my current
electricity billing rate.
Template of A User Story
Template of A User Story

▶ The user story template is designed to help Product

Owners and others tell stories with a clear “who”,
“what” and “why”.
Examples:
▶ As a registered user, I want to reset my password,
so that I can get back into the site if I forget my Password.
▶ As an unregistered user, I can sign up for the site, so

that I’m able to have a personalized experience.

▶ As Tom, I want to only see updates from close
friends, so that I can view relevant updates during
my time online.
Template of A User Story
•Getting Started:
•A simple statement in user story format
gets us started, but the delivery team still
needs more information.
Template of A User Story
 Template of A User Story
▶ Card
▶aplace to write “who”, “what”
“why” of a user story.
▶ A small space to tell a succinct story
that is easy to move around during
backlog prioritization.
▶ Capturesthe general idea and is the
promise for a conversation.
 Template of A User Story
Card
▶ Basis for a conversation between the Product
Owner and the Delivery Team, in which they
develop a sharing understanding of the
functionality goals and any constraints.

▶ The Delivery Team asks questions in order to

understand the underlying context and intent.
The Product Owner answers the questions,
using this input to drive a shared
understanding of what will be delivered,
removing any ambiguity.
Template of A User Story
Template of A User Story
Template of A User Story
Template of A User Story
Template of A User Story
Template of A User Story
Template of A User Story
 Template of A User Story

• ▶ The whole team can participate in

these discussions.
• ▶Different roles and different
viewpoints will surface different
questions and concerns.
 Template of A User Story

• ▶ What type of authentication do we

need?
• ▶ What information do we need to
collect about the user?
• ▶ Arethere different types of users
that we have to worry about?
 Template of A User Story

▶ Confirmation
▶ A well-defined user story is testable.
▶ As part of the conversation, the Product
Owner and the Delivery Team work together
to write acceptance criteria, “confirmation”
that the story is completed satisfactorily.
▶ High-level acceptance criteria statements
are usually sufficient.
Template of A User Story
Template of A User Story
 Template of A User Story

• Common acceptance criteria might

include:
• ▶Username, password, email addresses
are all required. Display name can be
provided, but is optional.
• ▶Passwords can be 6 – 100 characters in
length.
• ▶Passwords should be stored encrypted
and cannot be decrypted.
Acceptance
Criteria
“As a consumer, I want to be able to see my daily
energy usage so that I can lower my energy costs
and usage.”
Acceptance Criteria:
▶ Read DecaWatt meter data every 10 seconds and
display on portal in 15-minute increments and
display on in-home display every read.
▶ Read KiloWatt meters for new data as available and
display on the portal every hour and on the in-home
display after every read.
Hints for writing good user
stories
Hints for writing
good User Stories
Scenario:
Waiter asks for
▶ choice of soup or salad and bread
▶ Soup or (salad and bread)
▶ (Soup or Salad) and bread)
▶ The user can enter a name. It can be 127
characters.
▶ Blank?
▶ Less than 127
▶ More than 127?
▶ ATheme is a top-level objective that
may span projects and products.
▶ Themes may be broken down into sub-
themes.
▶ At its most granular form, a Theme may be an
Epic.
▶ Themes can be used at both Program and
Project Level to drive strategic
alignment and communicate a clear
direction.
▶ Epic represent a user story too
large to be done in one iteration (2
weeks)
▶ User Stories are “Spliced” Epics
Detail vs Priority
▶ Each story should be estimated in
points/man hours.
▶ Because the stories do not span more
than 2 weeks so the estimates
generally are much finer than Use case
estimates.
▶ The estimates may result in re-
planning of iteration .
▶ The estimates refined daily
▶ Requirementswill never freeze
but emerge and refine.
▶ Witheach iteration, the
emergent requirements need to
be detailed and planned.
• Prioritized
▶ Each user story is basically a business
value.
▶ If the requirements cannot be prioritized
beyond the common high, medium, and
low, they’re unsuitable for being called
as “User Story”.
 INVEST
▶ Independent
▶ Independence means that a story can be
developed, tested, and potentially even
delivered on its own. Therefore, it can also be
independently valued.
▶ Valuable
▶ An agile team’s goal is simple: to deliver the
most value given their existing time and
resource constraints.
▶ Backlogs are prioritized by value, and businesses
succeed or fail based on the value the teams can
deliver.
 INVEST ..
▶ Estimable
▶ A good user story is estimable.
▶ The team should be able to provide an
approximate estimation of its
complexity and amount of work
required to complete it.
▶ If the team is unable to estimate a user
story, it generally indicates that the
story is too large or uncertain. If it is
too large to estimate, it should be split
into smaller stories.
 INVEST
▶Small ..
User stories should be small enough to
be able to be completed in an
iteration
▶Increased throughput
▶(Cycle Time = Work in
Process/Throughput)
▶Decreased complexity
▶Rule 1: Do one thing
▶Rule 2: Keep them small
▶Rule 3: Make them smaller than that
 INVEST
..
▶Small
▶On the Relationship of Size and
Independence
▶Smaller stories increase the number
of dependencies
▶Smaller stories, however, even with
some increased dependency, deliver
higher value through put and provide
faster user feedback than larger
stories
 Testable
▶ All code is tested code
▶ If a story does not appear to be testable, then
the story is probably ill-formed, overly
complex, or perhaps dependent on other
stories in the backlog
▶ Write-the-test-first
Splitting User Stories
▶ Operations
(Example: Create Read Update Delete (CRUD))
Words like manage or control are a giveaway
that the story covers multiple operations, which
can offer a natural way to split the story.
“As a user, I can manage my account so that ..”
▶ Split into user stories:
▶ ...I can sign up for an account.
...I can edit my account settings.
...I can cancel my account.
...I can add more devices to my account.
Split …

• Story:
• “As a utility, I can sort customers by different demographics”
• ▶ Split:
•▶ ...sort by ZIP code
• ...sort by home demographics
• ...sort by energy consumption
User Stories vs Use cases
User Stories vs Use cases
▶Scope
▶Both are sized to deliver business
value
▶Stories are kept smaller in scope
because we place constraints on
their size (such as “no story can be
expected to take more than 10
days of development work”)
Example
Use Case Title: Compose and send email
message
Main Success Scenario
1. User selects the New Message menu
item.
2. System presents the user with the
Compose New Message dialog.
3. User edits email body, subject field, and
recipient lines.
4. User clicks Send button.
5. System sends the message
Story
▶ As a user, I can compose and
send email messages
▶ No hidden user interface
assumptions.
▶ With stories, the user interface
will come up during the
conversation with the
customer.
User Stories vs Use cases
▶ Purpose
▶ Use cases are written in a format acceptable to
both customers and developers so that each may
read and agree to the use case.
▶ The purpose of the use case is to document an
agreement between the customer and the
development team.
▶ Stories are written to facilitate release and
iteration planning
▶ Serve as placeholders for conversations about the
users’ detailed needs.
User Stories vs Use cases
▶ Defer collecting details
▶ An initial place–holding goal–level story can
be written and then replaced with more
detailed stories once it becomes important to
have the details.
▶ Write a few dozen stories to give them an
overall feel for the system.
▶ Plunge into the details on a few of the stories
and can be coding much sooner than a team
that feels compelled to complete an IEEE 830–
style software requirements specification.
User Stories vs Use cases
▶ Useful for Planning
▶ gives an estimate of how difficult
or time–consuming it will be to
develop;
▶ use cases are generally too large
to be given useful estimates.
▶ implemented in a single iteration
of an agile project
User Stories vs Use cases
▶Prioritize-able
▶Issuesdue to IEEE 830–style
requirements statements (“The
system shall...”)
▶consider the thousands or tens of
thousands of statements in a
software requirements specification
(and the relationships between
them) for a typical product.
Use Case & User Stories
• ▶ Use cases traversing a system identify where stories are
needed
•▶ See Page 377, 378 (Fig 19.5, 19.6);
Reference
Agile Software Requirements, Lean Requirements Practices for
teams, Programs, and the Enterprise by Dean Leffingwell;
Addison-Wesley, 2011.