How to write Good User Stories?

®
1 | 12/18/2019 © Copyright 2006-2018 Inflectra Corporation
How to write
Good User Stories?
Journey into Agile with Inflectra
By: Sriram Rajagopalan
We will be starting the webinar shortly, please stand by…
All phones will be automatically on mute until the Q&A.
Webinar Starts at 2:00 PM Eastern Time Zone

®
Meet the Speaker
Dr. Sriram Rajagopalan
Enterprise Agile Evangelist
Education
Work
Experience
Training &
Certification
Teaching
Experience
PhD, MBA, MS, BE
PfMP, PgMP, PMP, SP,
RMP, ACP, CSM, CSPO,
ACC, CSD, SCT, CSOXP,
SSBB, Instructional
Designer, Speaker,
Writer, and Author
Software Engineer,
Team Leader,
Business Analyst,
Project Manager,
Scrum Master, Agile
Coach, Director,
Vice President
Several
Colleges in the
US, India, &
Vietnam

®
Introduction
 Today’s webinar is part of the 4-part series on the third
webinar series “Journey into Agile with Inflectra”
 Each webinar is 1-hour long. We will reserve time at the end
for questions
 The webinars may introduce the concept using a tool

®
Journey into Agile with Inflectra - #3
AGILE ENGINEERING
PRACTICES FOR SOFTWARE
PRODUCT DEVELOPMENT
WRITING GOOD USER
STORIES
PATTERNS TO AVOID IN
AGILE CEREMONIES
INCORPORATING LEAN AND
KANBAN IN PRODUCT
LIFECYCLE MANAGEMENT
Dec 5, 2019 Dec 17, 2019 Jan 9, 2020 Jan 23, 2020

®
Experience Speaks
Regardless of the type of project delivery
framework selected, internal and external
stakeholders look at increasing value to
customer, increasing quality to product, reducing
time to market, and reducing cost to operations.
If user stories don’t target these four elements,
then, they don’t maximize benefits!
- Sriram Rajagopalan
Regardless of the type of project delivery
framework selected, internal and external
stakeholders look at increasing value to
customer, increasing quality to product, reducing
time to market, and reducing cost to operations.
If user stories don’t target these four elements,
then, they don’t maximize benefits!
- Sriram Rajagopalan

®
What’s the role of User Stories?
Daily Standup, 86%
Sprint/Iteration Planning,
80%
Sprint/Iteration Review, 80%
Retrospective, 80%
Short Iterations, 67%
Source: 13th State of Agile Surveys, 2019. Version One.

®
Four Practices to Writing Good User Stories
Practice #1
• Understand
Persona first
Practice #2
• See Big Picture
but follow
Company
Policy
Practice #3
• Iterate towards
1. “Get Ready”
2. “Get Done”
Practice #4
• Promote Team
Collaboration

®
Be Strategic about
Requirements Gathering
Starting
the
Problem
Half
Solved
Personify Users
Think holistically about the system
Practice #1
Understand the Users
Practice #1
• Understand
Persona first
Rule #2
• See Big Picture
but follow
Company Policy
Rule #3
• Iterate towards
“Get Ready”
State
Rule #4
• Promote Team
Collaboration
This Photo is from Pixaby and is licensed under CC BY-NC

®
User Story is all about the Relationships
Users Needs Product
Multiple Users
Persona Needs Assessment
User Stories

®
Use Case and User Stories Relationship
Use Case A
Use Case K
Use Case M
Product BacklogRoadmap
Iteration Backlog
Review
Need Features Design Element
Quality
Use Case
User Stories
Market
ResearchUse Case Z

®
Good Stories are
Stories identifying
specific goals to interact
with the product
Collection of stories that
represent the whole
Reduces technical
architecture risks
blocking implementation
Demonstrates value
allowing release of
partial functionality

®
Abuser Persona1
• Frustrated User
• Non-technical User
• Hacker
• User with disabilities
1. Rajagopalan, S. (2015). Abuser Persona. Retrieved December 2, 2019, from http://agilesriram.blogspot.com/2015/09/abuser-storieswhat-shouldn-software-do.html
2. Todaro, D. (2019). The EPIC guide to Agile. North Hampton, NH: R9 Publishing, LLC.
• Diversify User Persona to alternate interactions
• Expand User Persona for experience not intended
• Avoid failure from “Working As Designed” mantra
• Close the security loop holes (e.g. Backdoor)
• Don’t fall for YAGNI2 (You ain’t gonna need it)

®
Be Strategic about
Starting
the
Problem
Half
Solved
Continuously iterate through features
Follow Company Policies
Practice #2
See the Big Picture
Think global and Act local
Rule #1
• Understand
Persona first
Practice #2
• See Big Picture
but follow
Company Policy
Rule #3
• Iterate towards
“Get Ready”
State
Rule #4
• Promote Team
Collaboration
This photo is taken by Dr. Sriram Rajagopalan

®
Prerequisites for Backlog
• Neither too much nor too little information
Detailed Appropriately
• The user story should be unambiguous for one to estimate
Estimable
• It is dynamic and evolves through the iterations
Emergent
• Those that deliver the most value to the user should be at the top
Prioritized

®
User Story is a Contract
Card
ConversationConfirmation
Agreement between customer and team
Captures high level requirement
Describes details for planning estimates
Acceptance criteria for testing
User Stories are not meant to
substitute any documentation needs

®
Good User Stories
 Build a low-fidelity
model to begin
stories representing
user interface and
user journey
 Build Constraints
that require
prerequisite
functionality to be
developed
Home Page
Search Classes Browse Resources
Enroll for Class
Filter By Criteria
Preview Module
Monitor Engagement
Recommend ClassMonitor Enrollment
Give Promotion
*Shopping Cart
Enroll for Class*

®
Documentation Needs
Requirements Testcases
Defects Management
Tool should
accommodate as may
areas as possible
Tool should
automatically track
these elements
Tool should provide
interfaces for
management reporting
and custom reporting
Tool should enable a
project specific
dashboard for multiple
phases, iterations, and
releases

®
Be Strategic about
Starting
the
Problem
Half
Solved
Continuously Groom (DEEP – Invest)
Think of Acceptance Criteria
Practice #3
Iterate towards Readiness
Rule #1
• Understand
Persona first
Rule #2
• See Big Picture
but follow
Company Policy
Practice #3
• Iterate towards
1. “Get Ready”
2. “Get Done”
Rule #4
• Promote Team
Collaboration
This Photo by Unknown Author is licensed under CC BY-NC

®
Prerequisites for User Story
• Avoids planning & prioritizationIndependent
• Avoid too many details of precisionNegotiable
• Avoid technology implementation specific details.Valuable
• Story should be at a level for developers to estimate appropriately.Estimable
• Keep it simple by splitting storiesSmall
• Code it for automated testing as much as possibleTestable

®
User Story Format
As a “Frequent Flyer Member” I
want to “setup preferences for my
flight notifications” so that I can
“access the notifications at my
preferred communication channel.”
1. Easy access to the Notifications in the
GUI
2. Quick means to setup the grid of
available channel and flight notification
types
3. Email confirming my preferences
4. Message delivery confirmation on
Mobile
User Story A
Given “20% of unprocessed call
volume”, when “remaining time to
process the volume is less than two
hours,” then “a production alert
should be raised to increase the
ports or throttle.”
1. Expected hourly call volume is first
computed before initiating calls
2. Calls are prioritized by time zone for
processing
3. Separate process polls and records
real-time updates in dashboard
4. Call queuing is adjustable for new
ports or throttle adjustment
User Story B

®
Furthermore, Good Stories
• Agree with the team on what they
should build before they begin work
• Ensure everyone has a common
understanding of the business
need/impact
• Conform when a story can be
considered complete (DONE Criteria)
• Verify that the story can be tested
automatically for future iterations
Build Acceptance
Criteria
• What will the user most likely want
to do next?
• How can we prepare the user for
any information needed next?
• Where can the user be confused
looking for help?
• What errors may lead the user to
fail completing the goal?
Should extend
functionality
• Work that needs to be continuously
done in operations
• Guidelines around user interface &
screen captures for compliance
• Work developed by the vendor
under a different contract
• Some Cost of Quality initiatives
(like training, warranty)
Realize some
aren’t stories

®
Golden Rules from Best Practices
The WBS represents 100% of the
project scope with all internal
and external deliverables
100% Rule
The release plan represents 100%
of the MVP scope representing
value to customer and business
Every two weeks, there should be
a measurable and agreed upon
deliverable towards project
completion
2-Week Rule
Every two weeks, there should be
a measurable and agreed upon
MMF delivered in the iterations
No task in a WBS should exceed
40 hours regardless of the
resource expertise or the PM’s
bandwidth to monitor progress
40 hour
Rule
No user story exceeding [13 story
points] in size be committed by
the team regardless of the
resource expertise
PMI Framework Agile Framework

®
Be Strategic about
Buy-in Team commitments
Let the team focus on the “How”
Practice #4
Rule #1
• Understand
Persona first
Rule #2
• See Big Picture
but follow
Company Policy
Rule #3
• Iterate towards
“Get Ready”
State
Practice #4
• Promote Team
Collaboration
It is all about the TEAM
This Photo by Unknown Author is licensed under CC BY-SA-NC

®
Art of Agile Estimation
Idea
Epic 1
Theme A
Theme B
Epic 2
Theme C
Theme D
Feature I
Feature II
User Story a
Task I
Task ii
Task iiiUser Story b
User Story c
T0 T50
Time
Dreams Castles
Granularity
Big House Duplex Home 2 BR, etc. Get loan preapproval
Don’t estimate T-Shirt Sizes Story Point Hours

®
Let the Team work the Tasks
Why
(VALUE)
• What is the
business value for
the customer?
• What is the
business impact of
not building this
functionality?
• What is the
business impact of
deferring this later?
Who
(USER)
• Which types of
users are we
building this
functionality?
What
(OUTCOME)
• What is the specific
benefit of the
functionality?
How
(TASKS)
• What are the
specific activities
needed to be done
in what order to
deliver the
outcome?

®
Good story development means
Written in Active
Voice
Stories are
tagged with a
title instead of a
number
Accuracy of
Estimates evolve
as story becomes
granular
Scan the market
for missed
persona
Incorporate risks
proactively

®
Experience Speaks
Can we do
it?
Technical
Feasibility
Can we
sustain it?
Operational
Feasibility
Can we
afford it?
Environmental
Feasibility

®
Good User Story Development Practices
Practice #1
• Understand
Persona first
Practice #2
• See Big Picture
but follow
Company
Policy
Practice #3
• Iterate towards
1. “Get Ready”
2. Get Done”
Practice #4
• Promote Team
Collaboration
Stories identifying
specific goals to interact
with the product
Collection of stories that
represent the whole
Reduces technical
architecture risks
blocking implementation
Demonstrates value
allowing release of
partial functionality
Build a low-fidelity model to
begin stories representing user
interface and user journey
Build Constraints that require
prerequisite functionality to be
developed
Build Acceptance
Criteria
Should extend
functionality
Realize some
aren’t stories
Active Voice Text tagging Estimate
evolves
Scan for
persona
Incorporate
risks

®
Q & A
 Please feel free to ask
questions
Course Administration
Ms. Thea Maisuradze
marketing@inflectra.com
Content
Dr. Sriram Rajagopalan
sriram@inflectra.com.

®
Next Steps
1. Provide feedback to sriram@inflectra.com
2. Register for the 3rd webinar of the series!
Happy Holidays!
Thank you for watching!

How to write Good User Stories?

Recommended

More Related Content

What's hot (20)

Similar to How to write Good User Stories? (20)

More from Inflectra (20)

Recently uploaded (20)

How to write Good User Stories?

Editor's Notes