Training slides of User Story for Agile Development conducted for Product Owners at Dex One

1. Anantha Narayanan, CSPO, CSP
R. Anantha Narayanan, CSPO, CSP 1

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