2. AGENDA
What is a User Story ?
User Story Components.
Good User Story Format.
Need for User Stories.
How to Write a well formatted User Story.
INVEST Model.
Workshop Agenda.
R. Anantha Narayanan, CSPO, CSP 2
3. What is a User Story ?
A user story is a promise of future
conversation. [Ron Jefferies].
R. Anantha Narayanan, CSPO, CSP 3
4. What is a User Story ?
A user story describes the functionality or
features a product will deliver to a user.
R. Anantha Narayanan, CSPO, CSP 4
5. What is a User Story ?
Originally eXtreme Programming described
a user story as a small amount of text
written on an index card to function as a
reminder for a conversation between
developer and customer
R. Anantha Narayanan, CSPO, CSP 5
6. What is not User Story
A User Story is not a,
Detailed Requirement.
Technical Specification.
A Documented Contract.
Software Development Plan.
R. Anantha Narayanan, CSPO, CSP 6
7. What makes a User Story ?
R. Anantha Narayanan, CSPO, CSP 7
8. User Story Format
An agile user story can model USE, in
that case the format can be
“As a <User or role>
I want <Business Functionality>
So that <Business Justification>”
Example:
“As a <Account Holder>
I want <Mobile Payments>
So that <I can pay by my phone>”
R. Anantha Narayanan, CSPO, CSP 8
9. User Story Format
An agile user story can model Behavior,
in that case the format can be
“Given <User Scenario>
When <User Actions>
Then <System Behavior>”
Example:
“Given <The Screen is Mobile Checkout>
When <Pay Button Clicked>
Then <Process Payments>”
R. Anantha Narayanan, CSPO, CSP 9
10. How does the Conversations
become Real ?
When a Story has “ Acceptance
Criteria”.
R. Anantha Narayanan, CSPO, CSP 10
11. Acceptance Criteria
Acceptance Criteria helps verifying that
stories were developed such that each
works exactly the way the product owner
expected it to work.
In acceptance criteria story agreements
are documented by tests that
demonstrate that stories have been
developed correctly.
R. Anantha Narayanan, CSPO, CSP 11
12. Sample User Story in Card
Format
Credits: User Stories Applied for Agile Product Development, Mike Cohn.
R. Anantha Narayanan, CSPO, CSP 12
13. Why do we need User Stories ?
Output Outcomes
R. Anantha Narayanan, CSPO, CSP 13
14. Why do we need User Stories ?
Establish Verbal Communication between Product Owner and Developer.
R. Anantha Narayanan, CSPO, CSP 14
15. Why do we need User Stories ?
Make the Product Owner and Developer speak the same language
R. Anantha Narayanan, CSPO, CSP 15
16. How to write good User Stories
?
What is a good story ?
Needs a central character.
Has a plot.
Has a good ending, does not leave the
audience in limbo.
Gives something to the audience.
R. Anantha Narayanan, CSPO, CSP 16
17. How to write good User Stories
?
Identify your User
Identify Users Interaction with the Product.
Plot Usage and Behavior.
Decide the „Outcome‟.
Plan Validating the Outcome.
Be Ready to Send it for Publishing.
R. Anantha Narayanan, CSPO, CSP 17
18. INVEST Model
Independent
Negotiable
Valuable
Estimable
Small
Testable
R. Anantha Narayanan, CSPO, CSP 18
19. INDEPENDENT
Stories need to be independent for planning and estimating purposes
Stories must be Loosely Coupled.
Aim for Stand-Alone feature.
Avoid creating stories with
dependencies.
A company can pay for its ad campaign with a
credit card.
R. Anantha Narayanan, CSPO, CSP 19
20. NEGOTIABLE
Stories need to be negotiable so as to facilitate dialog between product
owner and developer..
Stories must be Emergent.
Aim for conversations.
Avoid creating stories with „should have‟
and „must have‟ constructs.
A user can search for a business based on
categories.
R. Anantha Narayanan, CSPO, CSP 20
21. VALUABLE
Stories need to be valuable for the end user in some form, either it
needs to add value or improve status-quo.
Stories must avoid technical
requirements.
Aim for conversions.
Avoid creating stories with zero sum
game.
A user can get a search result under a
second.
(Refactor front end code with warpdrive to
improve speed of loading)
R. Anantha Narayanan, CSPO, CSP 21
22. ESTIMABLE
Stories need to be estimated by the developers to a fair approximation
for the time it will take to complete the story.
Stories need to
be understood.
Avoid jargons,
be plain.
Help the
Developer.
A user can add review on a search result and
publish it .
(User can do yelp, stumble-upon and reddit)
R. Anantha Narayanan, CSPO, CSP 22
23. SMALL & TESTABLE
Stories size matters for planning , developing and testing
purposes.
Stories need to be right sized, not necessarily „Small‟.
Right Sized stories are mostly Testable.
Stories with functional features are generally testable.
It needs practice to become a „ Story Surgeon‟
A user can add review on a search result and
publish it .
I need an easy mobile experience to find the
local business.
R. Anantha Narayanan, CSPO, CSP 23
24. WHAT NEXT ?
Learn to build stories modeling context, constituents
and core values.
Learn to identify Thick Stories.
Learn to write good Acceptance Criteria.
Learn Techniques to identify „story split points‟ to break
down Epics.
Learn to avoid miniaturization syndrome.
R. Anantha Narayanan, CSPO, CSP 24
25. SEE YOU IN THE
WORKSHOP
Q&A
Thank You
Twitter: @tekzenpdm
tekzenpdm.blogspot.com
Credits: User Stories Applied for Agile Product Development, Mike Cohn.
R. Anantha Narayanan, CSPO, CSP 25
Editor's Notes
Detailed Requirements tend to close further conversations.Detailed Requirements have the propensity to become documented contracts.
A User with a set of tasks to do, and a story that tells about it.
This type of format is mostly used in Acceptance criteria but can some times be used to create user stories.
Output is like a software feature that is there because it is meant to be. Outcomes delight customers and it is what they expected.
In the example the red one is a developer requirement whereas the white one has a definite business value for the customer.
The idea is even for stories with complex details, write the narrative in plain English, Keep it SIMPLE