The document discusses user stories and how they can be used to improve communication between those building software and those wanting the software. It provides examples of well-structured user stories that include a template, acceptance criteria, and details on how specific and granular stories should be. Technical user stories are also discussed, which focus on non-functional requirements like infrastructure and refactoring rather than end-user functionality. The key benefits of user stories are outlined as being short and modifiable, allowing projects to be broken into small increments, and making effort estimation and development planning easier.

1. User Stories
A constructive narrative…

2. The Problem

3. The client
wants it to be
an elephant…
By tomorrow!
The Problem

4. Resultant: Business Assumes A Lot

5. Resultant: Unknowns Get Manipulated
 Trades quality
 Partial implementation of feature
 Takes decision alone which should have business
involvement.

6. WELL
STRUCTURED
USER STORIES

7. Solve The (Mis)communication
Those who build
the software
Those who want the
software
BETWEEN

8. What Is The User Story?
A concise, written description of a piece
of functionality that will be valuable to a
user (or owner) of the software.

9. 3 C’s Of The Story
• Card
• Conversation
• Confirmation
Mostly Supported by:
A Picture, that is worth
a thousand words…

10. C#1: Story Card
• A written description of the
user story for planning
purposes and as a reminder.
• A physical entity of reference.
• No Jargons.
• Written in direct speech.

11. C#2: Conversation
• A section for capturing further
information about the user
story.
• Details behind the story.

12. C#3: Confirmation
• A section to convey what tests will
be carried out to confirm the user
story is complete and working as
expected.
• Basically Acceptance test criteria.

13. User Story Template (One Of The Many)
As a [user role] I want to [goal] so I can [reason]
For example: As a customer, I want to withdraw cash from
an ATM, So that I don't have to wait in line at the bank.

14. Few Examples
• A user can search for jobs by attributes like location, salary range, job
title, company name, and the date the job was posted
• A user can view information about each job that is matched by a
search
• A user can view detailed information about a company that has posted
a job

15. How Detailed Should A User Story Be?
• Detailed enough for the team to start work from, and further details to
be established and clarified at the time of development.

16. Free of dependencies on other
stories and self-contained. Stories
can be completed in any order.
Stories that are negotiable can
always change with up to date
information before you begin work
on it.
Stakeholder, customers etc gets
some kind of value from that.
Clearly understood and have
enough details to estimate how long
does it take.
Able to be done in one iteration.
Large stories are difficult to plan
and estimate.
Contains key results or acceptance
criteria. How will you demo? Show
me! What has changed in the world,
now that the story is done?

17. User Story In Detail
USER STORY EXAMPLE: FRONT OF THE CARD
As s School User, I
want to be able to
offer my parents a
payment plan where
not all installments
are equal, especially
2 pay that are 60/40.
CARD
CONVERSATION
PICTURE

18. User Story In Detail
USER STORY EXAMPLE: BACK OF THE CARD
Scenario 1 – School Sets Up Plans
Given that School User is logged into the admin panel on
/mdForm/studentForm, when they add a new field:
• Under the Amount section, there will be a section for
Installments:
• The title will be “Installments”
• There will be a toggle button:
• It should look like the other toggles in the modal
• The default value should be Equal.
• When equal is selected, the table will not display;
• When equal is selected, the installment amounts
will be an even distribution of the total amount, as
per current functionality.
CONFIRMATION

19. Few More Examples

20. Can You Implement These Stories?
As a user, I want to cancel my order
• Does the user get a full or partial refund?
• Is the refund to user’s credit card or is it site credit?
• How far ahead must the order be cancelled?
• Is that the same for all orders?
• For all customers? Different requirements by market?
• Is a confirmation provided to the user?
• On-screen? Email? Letter?

21. Step1: Details As Condition Of Satisfaction

22. Step2: Breakdown In Smaller User Stories

23. The Pyramid In The Story
• A top level objective or visionTheme
• A group of related stories that
describes a particular higher
level functional
Epic
• The story with
INVEST(ment)
User Story
• Specific work sub-
tasks of the story.
Tasks

24. User Stories

25. Hands On - Part 1
• 20 mins Exercise.
• Write epics/user stories for a requirement (Time limit: 10 mins).
• Switch with person next to you and ask him to analyze the given user
stories.
• Update the stories for each other in next 10 mins.
Requirement: Going to office.

26. Technical Vs Business User Stories
• Technical User Story is focused on non-functional requirement
where as a business user story is focused on end user requirement
which has some business value

27. Technical User Stories
• A Technical User Story is one focused on non-functional support of a
system.
• Technical story focuses more towards technical debt and refactoring.
• Focus on performing technical analysis, design, prototyping and
architectural work.
• Focused towards underlying support for base functional behavior.
• Acceptance criteria or tests give you hints about technical stories.

28. Types of Technical User Stories
Technical
User
Stories
Product Infrastructure
Team Infrastructure
Bug Fixing
Refactoring
Spikes

29. Examples To Ponder…
• As a developer, I want to refactor the FooBar module so that it has less
duplication
• As a developer, I want to configure Jenkins so that we have continuous
integration
• As a product owner, I want to have the stories estimated so that we
can make a good plan
• As a tester, I want the test cases defined so I can test the system
What do you think of them???

30. Technical User Story == Technical Task
• Don’t get confused with the word ‘Story’.
• It does not necessarily follow the format of user story.
• Can be written in plain English.
• Should just have enough details.

31. Write Effective User Story
• User Comes First
• Use Roles to Discover the Right Stories
• Create Stories Collaboratively
• Keep your Stories Simple and Concise
• Start with Epics
• Refine the Stories until They are Ready
• Add Acceptance Criteria
• Don’t Solely Rely on User Stories

32. Pros And Cons Of User Stories
Pros:
• Short and Easy to modify as
and when requirements
changes.
• Allow projects to be broken into
small increments.
• Easier to estimate the
development effort.
• Completed User stories can go
for development.
• It drives the creation of
Acceptance tests.
Cons:
• Initial learning curve.
• They require close customer
contact.
• Rely more on the expertise and
inputs from the team. It’s a pros,
but becomes a cons if the team
is not self organizing.

33. Now Lets Practice…
Example1: "As a user I want to be able to manage ads, so that I can remove
expired and erroneous ads.”
Roles in a story
are as important
as Big B in
Bollywood!!!

34. Example 2: "As a Product Owner I want the system to have possibility of
deleting ads, so that users have possibility of deleting ads.“
Example 3: "As a developer I want to replace the folder widget, so that I
have better structured folder widget."
Project Roles =
Product roles
Except for few Exceptions…

35. • Example 4: "As an commercial advertiser I want to have filtering
option.”
What does
he want to
achieve???

36. Hands On - Part 2
• Time estimate: 1 hour (Execution: 30 mins, Discussion: 30 mins)
• Create user stories for the 2 Requirements.
• Prologue: I have an existing application, which can be used by many
doctors. This is the online platform where the doctors can connect to
their patients and also keep the data for their patients. The patients
can also come and interact and see his/her data on the same.
• Requirement 1: Send a personal message to Patients.
• Requirement 2: Patient Profile (To be done later)

37. Mail: agilecoe@clariontechnologies.co.in
Chatter: Agile@Clarion

38. Thank You!