All about User story

1. Monotype.
Monotype Agile Clinic
All about USER STORY
Sankalp Khandelwal
Agile Practitioner
Dec 2021

2. Monotype.
AGENDA
• What is a User Story ?
• What should a User Story have?
• User Story checklist
• INVEST
• Who can write the User Story?
• Splitting a User Story
• Stories vs Task
• DOD and DOR

3. Monotype.
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user
or customer of the system. They typically follow a simple template:
As a < role >, I want < goal > so that <benefit>
• Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is
initiating the activity.
• Goal – represents the action to be performed by the system.
• Benefit – represents the value to the business.
What is a User Story?
As an administrator
I want to create other administrators
So that I can delegate tasks.
As a marketer
I want to create automated email campaigns
So that I can keep evaluators engaged

4. Monotype.
Title: The title should be short and
descriptive.
01.
Acceptance Criteria: List of
scenarios that product manager will
use to test the story.
03.
TestCases:Testingscenario’shelpto
definethecompletionofuserstory.
05.
INVEST: User Stories should be
Independent, Negotiable, Valuable,
Estimable, Small and Testable.
07.
Description: Should have the
description of the features that are
of value to the user.
02.
Resources: Mocks, wireframes, user
flows, and other assets that can help
to explain user story.
04.
Functional &Non-functional
requirements: The requirements that the
end user specifically demands as basic
facilities that system should offer.
06.
What should a User Story have?

5. Monotype.
Title:
• Create a password interface for the banking customer.
Description:
• As an online banking customer, I want a strong password, so that my credit card information is secure.
Acceptance Criteria:
• The password must be at least 8 characters.
• The password must contain at least 1 character from each of the following groups: lower case alphabet, upper case alphabet, numeric, special
characters (!, @, #, $, %, ^, &, *).
Test Cases:
• Verify if the login is possible with a valid password.
• Check if the backspace or delete keys help in removing entered information in case wrong credentials are entered.
• Check if an error message appears for an invalid password.
• Verify that login is not possible with the wrong credentials.
• User should not be able to paste the password.
Non-functional requirement:
• The password shall be changed a maximum of every 60 days.
Sample User Story

6. Monotype.
Keep them short.
Keep them simple.
Write from the perspective of the user.
Make the value/benefit of the story clear - what is the reason for the story?
Describe one piece of functionality. If you have to write and break it into 2
stories.
Write stories as a team. Use acceptance criteria to show a MVP.
Not required to be fully technical.
User story checklist

7. Monotype.
INDEPENDENT
User Stories should be as
independent as possible.
VALUABLE
User Stories should be
valuable to the user. They
should be features, not
tasks.
ESTIMABLE
User Stories need to be
possible to estimate. They
need to provide enough
information to estimate.
SMALL
User Stories should be
small. Not too small. But
not too big.
TESTABLE
User Stories need to be
worded in a way that is
testable.
NEGOTIABLE
User Stories are reminders of
features for the team to discuss and
collaborate to clarify the details
I N
T
S
E
V
INVEST

8. Monotype.
THE GOOD

9. Monotype.
THE BAD

10. Monotype.
THE UGLY

11. Monotype.
• Anyone can write user stories.
• It's the product owner's accountability to make sure a product backlog of user stories exists.
• Also, note that who writes a user story is far less important than who is involved in the discussions of it.
Who can write user stories?
• They are written throughout the agile project.
• Everyone on the team participates with the goal of creating a product backlog that fully describes the
functionality to be added.
• Some of these user stories can be epic Epics will later be decomposed into smaller stories that fit more readily
into a single iteration.
When are user stories written?

12. Monotype.
Splitting User Story
Why is splitting User Stories important?
• Story splitting user stories avoids overwhelm by giving the team smaller, more manageable pieces of work.
• Story splitting helps teams deliver value to customers early and often.
• Story splitting changes the mindset from thinking about layers of development to the experience of the
user.
• Story splitting requires that the team prioritises the highest-value goals and features for users.
— Story Splitting is the process of breaking one single user story into smaller stories. However, it’s not about
breaking it into component tasks, but rather complete stories or slices that still deliver value to the user.

13. Monotype.
Techniques to split a User Story (S.P.I.D.R)
Interfaces in this context can
for example be different
devices or device types.
INTERFACES
Business rules or
technological standards can
be another splitting factor
RULES
This can be used when the initial
stories refer only to a sub-range of
the relevant data.
DATA
If there are several possible
alternative paths in a user story
PATHS
This method involves investigations
and building knowledge
SPIKES

14. Monotype.
Stories vs Task
STORIES TASK
• A task = the HOW
• A task is something like code this, design that,
create test data.
• These tend to be things done by one person.
• Tasks are restricted to a single type of work.
• It can be technical Story (tech debt, architecture ,
spikes , technical prototype)
• A User story = the WHAT
• User story will be visible to end users.
• It would be very rare for a user story to be fully developed
by a single person.
• Stories contain multiple types of work (e.g., programming,
testing, database design, user interface design, analysis,
etc.) Tasks are restricted to a single type of work.

15. Monotype.
Definition of Ready
(DOR)
• Has Acceptance Criteria that can be tested
objectively.
• Estimated by the entire development team.
• Socialized with the entire team.
• Has the right size that can be
• completed within a Sprint.
• Complies with the INVEST Model.
• No external dependencies.
Definition of Done
(DOD)
• Satisfies its Acceptance Criteria
• Tested (e.g., for software/hardware)
• Validated (e.g., for design documents,
models)
• Demonstrated to the stakeholders
• There are no must fix defects left
• Relevant documented
• Accepted by the Product Owner

16. Monotype.
At the end of the day, formulating features in the shape of user stories helps you stay focused on the business objectives
What is User Story
• User Story is a short, informal, plain language description of what a user wants to do within a software product to gain
something they find valuable.
As a < type of user >, I want < some goal > so that < some benefit >
Who writes user Story
▪ Well, it depends. If your team has agreed to capture features in the form of user stories, it is most likely that they'll come
from the shareholders through the Product Owner.
Splitting User Story
▪ The INVEST principle is a guideline to help you validate if the user story you have written is a good one.
▪ SPIDR can used for the User stories that are extremely large, but they also contain many smaller stories and can thus be
split.
When to write Story vs Task
▪ "User Story" will contain the what, and the "Task" is the how of the work that needs to be done.
To summarise...

17. Monotype.
Q&A

18. Monotype.
Thank you.