1
User Stories – The Art of Writing Agile Requirements
Speakers: Susana Esparza & Raj Indugula
Company: LitheSpeed
Website: lithespeed.com
Welcome to the PMI Houston Conference & Expo and Annual Job Fair 2014
• Please set your cell phone to silent mode
• There will be time at the end of this presentation for you to take a few
moments to complete the session survey. We value your feedback which
allows us to improve this annual event.
2
Agenda for Today’s Workshop
• Introduction
• Overview of Agile/Scrum
• From Vision to Acceptance Criteria
! Modeling Users & Customers
! Epics, Features & User Stories
! Elaborating from Vision to Story
! Acceptance Criteria & Testable Examples
• Q & A
1. Find a partner.
2. Start telling them about yourself.
3. When they hear something you both have
in common, they will say “Me Too!” and
find a new partner.
An Introductory Exercise
3
Business
Wants
Development
Builds
QA Tests
Problem Context: Communication
4
Development
Business
Striking a Balance
5
Overview
Agile & Scrum
7
The Agile Landscape
“Agile” describes a number of
related methods.
Scrum is the most popular.
• Scrum
Jeff Sutherland & Ken Schwaber
• Extreme Programming (XP)
Kent Beck, Ward Cunningham, Ron Jeffries
• Kanban
David Anderson
• Scaled Agile Framework (SAFe)
Dean Leffingwell
Scrum&
Scrum&/&
XP&
!"#$%&'()*+*(!,-,&(".(/012&(
3&4&2"56&7,(!#$4&89(:&$;1"7<7&(
8
Dealing with Uncertainty
Better Plan
Use&agile&when&&
you&have&uncertainty…&
&
What&to&build:&=7>(?7%&$,-17,8(
How&to&build&it:&@&-7;(?7%&$,-17,8(
Who&to&build&it&for:(?;&$(?7%&$,-17,8(
(
(
(
You&don’t&need&agile&if&you&know&what&to&build,&who&to&
build&it&for,&and&how&to& build& it&
Initial Plan
Empirical methods
monitor progress &
direct adaptation
9
Ceremonies and Artifacts of Scrum
Burndown
* Discovery is not explicitly part of the Scrum Framework
Initial Planning
Sprint Cycle
“Done”
Features
For this Sprint
Product
Backlog
Sprint
Backlog
Initial
Discovery *
Release
Planning
Sprint
Review
Daily Scrum
Work
Sprint Retro
Sprint
Planning
“Ready”
Features
For next
Sprint or two
Continuous Discovery
Backlog
Refinement
Led by Product Owner with help from Team
Led by Team
Product
Validation
In-Sprint
Feedback
Continuous Delivery
10
Roles
Roles
Process
Retrospective
Blockers
ScrumMaster
Values, Practices, Rules
Burndowns
Vision
ROI/Product
Backlog
Release
Plans
Product Owner
Product Backlog
Trade-Offs
Team
Shippable Functionality
Sprint Planning
Daily Scrum
Deliverables
Sprint Backlog
11
Tools
PB Item Priority Size
User Story High 2
User Story High 3
User Story High 5
User Story Medium 2
User Story Medium 13
PBI Medium 8
User Story Medium 8
User Story Medium 13
PBI Medium 20
User Story Low 100
User Story Low 40
SB Item Priority
User Story High
Task 1
Task 2
Task 3
User Story Medium
Task 1
Task 2
Task 3
User Story Low
Task 1
Task 2
• Product Backlog
Prioritized list of all items (PBI) required
to launch a successful product
• Sprint Backlog
Tasks to get committed
PBIs to done within Sprint
• Task Board
Stories and tasks for the Sprint
tracked from start to completion
• Burndown/burn-up Chart
Visual aid for tracking team
progress and forecasting expected
completion dates
0
100
200
300
400
500
300
390
420
410
400
140
100
60
30
0
12
The Big Picture
Vision
Aligning Goals & Constraints
For Target Customers
Who Statement of Need
The Product Name
Is a Category
That Compelling Reason to Buy & Use
Unlike Competition / Alternative
Our Product Differentiator
As described by Geoffrey Moore in Crossing the Chasm
(Thanks to Gabrielle Benefield for the reference)
Crafting a Vision Statement
14
Simulation
Restaurant Finder
Create a Vision Poster for your
simulation project with:
1. A product name;
2. A product logo;
3. A product slogan or jingle; and
4. Three (3) compelling reasons to buy
your product.
Exercise – Prepare a Pitch
16
Personas
Customer & User Modeling
18
Users vs. Customers
Users interact directly with the system
They are important to understand, because:
• Knowledge of current usage patterns helps to design better, more
usable systems.
• Unsatisfied users will work around the system, nullifying its advantages
and eventually eliminating it.
Customers (sponsors) make buying / adoption decisions
They are also important, because:
• They have their own wish lists that may have little to do with their
users’ needs.
• They make the purchasing decisions, so if they aren’t happy, you won’t
get in the door.
19
Looking Across Usage Scenarios
• Personas represent a type of user across
usage contexts.
– One member of our current or desired audience
in a tangible, less ambiguous way.
– Provide a name, a face, and a description giving
us a mental model of our users allowing us to
emphasize with them and predict how they will use
our software.
• Level of detail
– Add just enough detail to aid empathy, more details
can be distracting.
– Lightweight personas will suffice for many.
20
User Models Summary
• Use what works user roles, personas, etc., without
getting hung up in vocabulary.
• Prioritize your user(s) and prioritize stories for them.
• Post big charts (e.g. personas) in team room to aid
empathy.
• Focus testing and evaluation on the right users,
identifying test subjects similar to your models.
• Base models on reality (ethnography / field study):
• Usability Testing
• Observation
• Interviews
• Data Analysis
• Feedback Forms
• Surveys, etc.
21
Exercise: Create Personas
Who are your most critical
personas, or early adopters?
1. List potential stakeholders that would
represent the Customers & Users of your
product.
2. Prioritize these stakeholders and pick
two to elaborate.
3. Create at least two personas by writing
brief stories that outline the motivations
and goals of these customers or users.
User Stories & the Backlog
Working with Agile “Requirements”
23
User Stories
The basic user story template is simplistic, it helps us
remember a need while providing context.
As a customer who drives
I want to find a conveniently
located branch
So that I can minimize
driving time
User Role, Persona
(Who?)
Desired Function
(What?)
End Result
(Why?)
AB-,(1;(7",(;5&%1C&>D(
Key Characteristics
• High-level descriptions of
desired functionality and goals
• “Contracts for conversation”,
not all-inclusive requirements
• Pulled into the Sprint Backlog
from Product Backlog
• Contain Acceptance Criteria to
define “Done”
• Vertical slices of the system’s
functionality
Work in Agile projects is organized by Units of Value,
rather than by Architectural Layer.
24
Product Backlog User
Story
Sprint Backlog
User Stories
As a user I want to create
an account so that I can
shop online.
Estimate 13 Points
Priority 1 (High)
As a user I want to
enter my billing
information.
Estimate 4 points
Priority 1 (High)
As a user I want to
enter my personal
information.
Estimate 4 points
Priority 1 (High)
User&&
Story&
UI
Business
Logic
Persistence
User Stories at a Glance
25
What Makes a Good Story?
Bill Wake’s INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testable
Ron Jeffries’ 3 Cs
Card
Conversation
Confirmation
26
User Stories: Invest - Independent
• If all stories are independent, any one can
be picked and delivered in isolation
• For large systems this is nearly impossible!
• But, minimizing, identifying and prioritizing,
dependencies can result in a better backlog
• Which user story must come first?
Order
Checks
Transfer
Pay Bills
Register
Login
PO: I want
“Pay Bills”
now!
As prospect
I want to register
So that I can
execute electronic
transactions
As a user
I want to pay bills
online
So that I don’t have
to write checks
27
User Stories: Invest - Negotiable
• Leaving room for give and take and decide
the details when you have more context
– High priorities stories should be more
precisely defined
– Low priority stories should have more play
As a driver
I want to get directions to
conveniently located stores
So that I get there quickly
Essence today
Details
later
Acceptance Criteria:
Show locations on map
Show locations on Google
Maps
Defer details until you are close
to building, in this case update
the acceptance criteria
28
User Stories: Invest - Valuable
The user story must have value to the user and to the business
As a user
I want to have my
previous orders stored
in the database
So they will be there
permanently
As a repeat customer
I want to access old orders
So that I can quickly
purchase the same products
again
There is clearly
value to the user,
but is there value
to the business?
As a customer
I want 75% off all
purchases
So I can save money
29
User Stories: Invest – Estimable/Small
• If you can’t estimate it, it is either too large, too
vague, too risky, or some combination thereof
• Solutions include adding acceptance criteria,
splitting the story, or better defining it
As a customer
I want a self service center
So that I can address basic
needs 24 by 7 by 365 from
my computer
Too big?
As a customer
I want to see my
canceled checks online
So that I can confirm
transactions
As a customer
I want to stop payment
on check so that I an
prevent a payment
made in error
As a customer
I want to find an ATM
So that I can make
deposits or with-drawls
outside of banking hours
Easier to estimate,
perhaps small
enough to complete
in a few days
Acceptance Criteria:
1. Stop payment on check
2. Find a branch
3. Find an ATM
4. Order new checkbook
5. Get statement < 2 years old
As a customer
I want to find a nearby
branch
So that I can conduct
business in person
30
User Stories: Invest - Testable
• You need clarity on the story specific done criteria
• Solutions include adding acceptance criteria
or better defining the story
As a registered user
I want a better looking
homepage
So that I don’t have to look at
something so ugly
Acceptance Criteria:
1. All text is dark color on light
background (no more red on
black)
2. Only two different fonts used
(instead of seven)
?????
Have to manually test, but it is
clear.
31
Epics
Features
Stories
Product backlog
Priority
Epics, Features, Stories
Epics are high-level features or activities
that span Sprints, or even Releases.
• Add a Customer Center for self service.
• Improve database response time by 50%.
Logistics
• The PO works with stakeholders and the Team
to create epics that address desired Goals.
• Epics are often defined prior to Release Planning.
• Often months of effort.
Epics
32
Features are tangible expressions of
functionality, but still too large to build.
• As a Bank Customer, find a branch so that I can deposit
checks.
• As a Shopper, set up a mobile wallet so I can pay for
purchases via Near Field Communications.
Logistics
• Created by the PO with input from the team
• Often defined prior to Release Planning
• Decomposed over time to smaller Stories
• Typically weeks of effort
Features
33
User Stories are ready for the Team to
build.
• As a Bank Customer, find a branch near an address so that I
can minimize travel.
• As a Shopper, add an account to my mobile wallet so that I
can fund it.
Logistics
• Refined in backlog grooming sessions by PO
and representatives from Team
• Stories should be well-defined prior to Sprint
Planning
• Generally about 1-3 days of effort
User Stories
34
35
Non- Functional Requirements (NFRs)
• System-wide nonfunctional requirements may
become part of the Definition of Done.
• Articulated as tests
• Serve as design constraints
Search response time will not exceed 10 seconds.
All stories will meet Section 508 accessibility
guidelines.
• Story-specific NFRs are expressed as
Acceptance Criteria.
User Stories Requirements
(User Stories ! Requirements)
36
36
What User Stories are NOT
37
Context (Project Vision, Business Case, etc.)
User Story
Conversation(s)
Acceptance
Criteria
+ +
Supporting
Information
+
Common Understanding of a Need
Requirement
=
37
Requirements, More than Just a Story
A B
As a prospect
I want to enter my billing
information
As a prospect
I want to register
So I can make purchases online
As a driver
I want to find the store with the
shortest drive time
So I can get there quickly
As a driver
I want to find directions to a store on
Google Maps
So I can get there quickly
As a repeat customer
I want to access old orders
So that I can rapidly purchase the
same products again
As a user
I want to have my previous orders
stored in the database
So they will be there permanently
As a color blind user
I want dark text & light background
So that I can easily read the text
As a user
I want a nice looking site
So my aesthetics are satisfied
Which Story is Better?
38
39
Exercise – Write User Stories
Using the Epics we provided for our
awesome restaurant finder app:
• Create at least five Sprint-sized
User Stories based on these Epics.
• Use the “As a, I can, so that”
format for the User Stories.
Release Planning/Roadmapping
Story Maps
• Minimize the time
needed to access
patient records
• Minimize the customer
inputs necessary to
access patient records
Night Nurse
Robin
Robin leaves for work at 6pm, after
sleeping during the day. She works a
7pm-7am shift in Labor & Delivery,
caring for prospective mothers and
their babies. Complex computer
apps make Robin grumpy.
User Goals
Persona
Epics
Workflow Sequence
Priority
Features &
User Stories
Access
record
Review
history
Provide
Nurse ID
Search
records
Provide
Patient ID
Sort
records
Filter
records
Update
record
View
history
Add
comment
Search
history
Enter
updates
Reference
validation
Notify of
updates
Medical
Reference
Search
reference
Add
comment
Release
Boundary
41
Mapping Releases with Story Maps
Thanks to Winnipeg Agilist for this image
42
Another Example
Value is influenced by many things:
• Time sensitivity – Build features that decay in
value over time earlier.
• Uncertainty & Risk – Use “spikes” to test
market or technical viability for critical, risky
features.
• Size – All else being equal, do the shortest first.
• External Dependency – Third party or support
group dependencies can be immutable
constraints.
43
Prioritization Parameters
Plan your first few Releases with a
Story Map.
• Place Epics or High Level Activities at top, in
order of their natural workflow as appropriate.
• Place User Stories underneath the Epics that
they support, from top to bottom by value.
• Group the stories for your first Release (MVP)
and subsequent Releases, describing the
targeted benefits of each at a Roadmap level.
44
Exercise – Story Mapping
Product Backlog Management
Refining, Accepting & Testing
Adding User Stories
• Anyone can suggest backlog items
• Product Owner prioritizes them
Estimating & Elaborating
• High-priority items are estimated and
described most precisely, since they
will be worked on first
• Low-priority items are generally
estimated and described coarsely
Prioritizing
• Ordering is driven mainly by business
value and risk reduction.
# Backlog Item Estimate
1 Create login screen 1
…
20 Allow user to browse
recently viewed items
8
…
60 Add personalization 30 (or so)
High priority items
are better defined
Low priority items
are often “epics”
46
Product Backlog Essentials
IdeaFon&
&
&
@-$E&,(F$&7>;(
G$",",85&;(
H"%#;(I$"#5;(
?;&$(=J5&$1&7%&(
K-;1%(A"$EL"M;(
:1;1"7(
K#;17&;;(<#,%"6&;(
N&2&-;&(F16170(-7>(I"-2;(
G$">#%,(/$%B1,&%,#$&(
=51%;(-7>(H&-,#$&;(
MaturaFon&
&
&
?;&$(!,"$8(3&%"65";1O"7(
?;&$(!,"$8(@-,#$-O"7(
/%%&5,-7%&(P$1,&$1-(
F&;,(P-;&;(
3&5&7>&7%1&;(
!,"$8(@-55170(
G$1"$1OQ-O"7(
=51%(=;O6-O"7(
K-%E2"0(3&4&2"56&7,(
&
&
&
&
ExecuFon&
&
&
!5$17,(G2-77170(
!5$17,(=;O6-O"7(
3-128(!,-7>#5;(
!"RM-$&(3&4&2"56&7,(
F&;O70(
K#$7>"M7;(
3"%#6&7,-O"7(
G$">#%,(3&6";(
N&,$";5&%O4&;(
&
&
&
Current Sprint ~1-2 Sprints ahead 3-4 Sprints ahead or more
Marketing/Sales,
Product Management,
Product Owners,
Architects
Product Owners,
Architects, Dev Leads,
QA Leads, UX/Analysts
Leads, UX/Analysts,
Dev Team Members
47
Progressive Elaboration
• Phone # in US format, contains no alpha
characters, minimum 10 digits
• First name, Last name and email address
required
• Email specified in standard format
Acceptance Criteria
Sprint Pre-Planning (Backlog Grooming)
As a user
I want to create an account
So that I can shop online
Priority – 1 (High)
User Stories
Created during upfront and ongoing Discovery
Sprint Tasks
Sprint Planning
• Design UI Mock Up
• Write online help text
• Develop CSS/HTML
• Develop validation criteria
• Create database tables
• Code test fixtures
• Code & Test
Name Phone Email Valid
John Smith 215-555-1212
TRUE
Smith 215-555-1212
FALSE
John 215-555-1212
FALSE
215-555-1212
FALSE
John Smith
FALSE
Smith
FALSE
Testable Examples (ATDD)
Sprint Pre-Planning (Backlog Grooming)
Estimate - 5 Points
48
Maturation of a User Story
The tactical act of getting a story ready is often
performed as a two sprint look-a-head by an amigos
team
Select User Story 999 for Sprint n
+2
Re-estimate it, sharpen story &
acceptance criteria
Create testable example and other
supporting material for 999
Get sign off from external parties
Develop
User Story 999
Sprint n Sprint n + 1
Sprint n + 2
The PO and 3+ Amigos look-
a-head and select story 999
for inclusion for Sprint n + 2.
They do cleanup on the story.
The 3+ Amigos further
support the story and the PO
gets appropriate sign offs.
Story 999 makes it’s way into a
sprint and it is built.
Sample Story Maturation Look-A-Head
49
ds…
1. To Demonstrate Progress: UX with no validation or save
2. CRUD: Create, report, update & delete (e.g. split of manage)
3. Basic to Advanced: Sort by one field (name), sort by any one
field (name, date, etc.), sort by a combination of fields
4. Use Case scenarios: Happy path, alternates, exceptions
5. Workflow steps: Find book, see details, purchase
6. Importance: Credit card, split across cards, automatic billing
6. UI complexity: Manual coordinates, interactive web map
7. Spike and Build: Research credit card processing, implement
50
Approaches to Splitting Stories
50
1!
As a …
I want to manage my
widgets!
2!
As a report viewer
I want to filter my report by
any combination of columns !
3!
As a possible room renter
I want to find and book a
room!
4!
As a customer
I want to pay electronically!
Split some Stories
51
5!
As a low budget vacation
traveler
I want to find flights using a
range of dates!
6!
As a credit card purchaser
I want to pay by Amex,
MasterCard, Visa or Discover !
7!
As a frequent user
I want to personalize my
experience!
Split some Stories
52
53
Getting to Ready
ST(/610";(UK/9(V/9(3&4W(%-7(
;&$4&(-;(-($&->17&;;(,&-6(,"(2""E(
-B&->(-7>(&7;#$&;(M&(-$&'(
(
+X N&->8(,"(5$1"$1OQ&(
)X N&->8(,"(&;O6-,&(Y($10B,(;1Q&(
SX N&->8(,"(Z#12>(
54
When is a Story “Ready”?
DefiniFon&of&“Ready”&
• PB"";&(,B&(few&items&,B-,(8"#$(,&-6(C7>;(6";,(#;&.#2(17(!5$17,(G2-77170X(
• P"7C>&7,(-7>(quick&Sprint&Planning&-7>(smooth&Sprints&,B-,(5$">#%&(
5"21;B&>($&;#2,;(-$&(8"#$(0"-2;X(
" [7,&$-%O"7(31-0$-6;(
# G$",",85&;(
# A1$&.$-6&;(
" !-652&(3-,-(
" F&;,-Z2&(=J-652&;(
" /%%&5,-7%&(P$1,&$1-(
# !,-,&(31-0$-6;(
" !6-22(=7"#0B(
# /0$&&6&7,(.$"6(",B&$(,&-6;(
# /55$"4-2;(UP"6521-7%&9(!&%#$1,89(
K$-7>(@06,9(&,%XW(
# 3&5&7>&7%8(\1;,(
# !,-E&B"2>&$(;107"](
55
When is a Story “Done”?
DefiniFon&of&“Done”&
• /(shared&definiFon&-7>(%"65-%,(Z&,M&&7(F&-6;(-7>(!,-E&B"2>&$;(
• 3&7",&;(MB-,(;,"$1&;($&^#1$&(,"(Z&(accepted&
• [>&-228($&5$&;&7,;(“potenFally&releasable”&"$(&4&7($&2&-;&>(;,-,&(
" /%%&5,-7%&(P$1,&$1-(-$&(6&,(
" P2&-$&>(Z8(V/(
" /%%&5,&>(Z8(F-%O%-2(G<(
" /%%&5,&>(Z8(!,$-,&01%(G<(
# \14&(."$(/YK(F&;O70(
# H17-2(3&52"86&7,(
# F$-17170(!%$15,(
" G-1$($&41&M&>(
# G&&$(N&41&M&>((
" [7,&0$-,&>(
# \10B,M&10B,(#;-Z121,8(,&;,&>(
" /#,"6-,&>(,&;O70(17(52-%&(
" ?;&$(>"%#6&7,-O"7(%$&-,&>(
" <5;(>"%#6&7,-O"7(%$&-,&>(
56
“Done Done” at Release Level
What are the
minimum criteria for
each Release?
• Testing/quality targets
• Performance targets
• Operational (e.g. sales/
marketing) deployment
goals
• Required
documentation &
artifacts
• Regulatory compliance
targets
Example Release Criteria
• System response on all
level 1 functions within 5
seconds
• No Severity 1-3 bugs in
Firefox 2+, Chrome, IE 7+
or Safari 3+
• No Severity 1 or 2 bugs
found during final month
• Full compliance with
accessibility guidelines in
Section 508
Acceptance Criteria &
Testing
58
Acceptance Criteria Example
As a user
I can cancel a registration
So that I don’t have
to pay
# Premium member can cancel the same
day without a fee
# Non-premium member is charged 50% of
first day for a same-day cancellation
# Email confirmation is sent to members
primary and secondary email addresses
# Hotel is notified of any cancellation
Conditions of Satisfaction –
Broad Terms
Acceptance Criteria –
Further Refined
Examples –
Actual scenarios or data
Executable Examples –
Ready to automate
Modern Agile Acceptance Model
59
Testing a Registration Function
• What constraints should we impose?
• Business stakeholders and PO agree that
passwords should not be easy to
crack.
Please fill in to register.
Email Address
Password
Register
Acceptance – Conditions of Satisfaction
60
Acceptance Criteria, the Details
The PO works with testers and developers from the team,
business stakeholders, users or SMEs to come up with this
definition of “not easy to crack”:
• Must be at least 8 characters and no more than 12
• Must contain only alphanumerics and the period
• Must contain at least one digit
• Must contain at least one alpha character
Please fill in to register.
Email Address
Password
????????????&
61
Acceptance – Acceptance Criteria
61
• Examples, Making it Real
• Actual examples are the ultimate way to communicate
requirements
• Team Members with testing and development expertise take the lead on
creating examples, with the Product Owner verifying
• Based on these examples, Acceptance Criteria can be refined
• These criteria act as good starting test cases too
Password Expec
ted
Expected Message Comment
abc123 Invalid You password must be at least 8 characters long, and no more than
12 characters long.
abcdefghi Invalid Your password must contain at least one character and one number.
1aaaaaaaaa Valid Why valid?
ajx972dab Valid
Acceptance – Examples Written
62
• Executable Example, Making it Repeatable
• Examples that can be executed are the final
step
Given the “Unregistered User” user has navigated to the “register” page
When entering “newuser” in the “Username” field
And entering “abc123” in the “Password” field
And entering “abc123” in the “Confirm Password” field
And pressing the “Register” button
Then the text “Thank you for Registering” should appear on page
And the URL should end with “use/accountPage”
Acceptance – Testable Examples
63
A practice in which the whole team
collaboratively discusses acceptance
criteria, with examples, and then distills
them into a set of concrete acceptance tests
before development begins.
- Elisabeth Hendrickson
64
Acceptance Test Driven Development
(ATDD)?
64
1. Elicit details from the business
stakeholder(s) about their expectations
2. Distill acceptance criteria into automatable
tests expressed in a natural language
3. Wire the tests to SUT with “glue” code (as
part of implementation)
65
ATDD - Key Characteristics
65
Tool
(Cucumber, SpecFlow, FitNesse)
Specification
expressed in
common language
“Glue” code that
ties specification
to SUT
66
Automated Acceptance Tests
66
67
67
68
Exercise – Write acceptance tests
Create testable specifications
Using the User Stories you defined
• Write acceptance criteria for each story
• Create at least two scenarios to act as
examples and tests, using this format:
Scenario:&Recent&Account&AcFvity&
Given&[(-6(-($&01;,&$&>(#;&$(_`;61,Ba(
(((/7>([(-6(2"00&>(17(M1,B(5-;;M"$>(_J8J+)Sa(
(((/7>([(B-4&(B->(-%%"#7,(-%O41,8(17(,B&(2-;,(bc(>-8;(
When([(%21%E(,B&(_N&%&7,(/%O41,8a(Z#d"7(
Then([(;B"#2>(;&&(,B&(_/%%"#7,(/%O41,8a(G-0&(
(((/7>([(;B"#2>(;&&(-(21;,(".(68(-%O41,8("4&$(,B&(2-;,(bc(>-8;(
Common pitfalls with writing user stories
• Forgetting about the User
• Too much Detail
• Lack of Conversation
• No Acceptance Criteria
Concluding Thoughts
69
70
Speakers: Susana Esparza & Raj Indugula
Company: LitheSpeed
Website: www.lithespeed.com
Phone: 703.745.9125
E-mail: [email protected]
Thank You
Contact Information
71
Thank you for attending this session.
We hope you found this presentation
added value to your knowledge of
Project Management.
• Take a few moments to complete the Session Survey. We appreciate and
value your feedback.
• Hand in your completed survey to Registration, you will receive a free raffle
ticket for one of the drawings to be held in the Vendor Expo (see Conference
Program Guide for details).
