The document provides guidance on writing clear and effective user stories from start to finish. It recommends beginning with the end in mind by focusing on who the user is, what they want to do, and why. Stories should have well-defined acceptance criteria and follow INVEST principles by being independent, negotiable, valuable, estimable, small, and testable. The document provides tips for clarifying user roles through personas, ensuring consistency across stories, properly sizing stories, and splitting large stories into smaller pieces. The overall message is that diligence is needed to hone stories from fuzzy concepts into sharp, implementable tasks.
Amazon Bedrock in Action - presentation of the Bedrock's capabilities
User Stories: From Fuzzy to Razor Sharp
1. 6/2/2015
1
User Stories: From Fuzzy to Razor
Sharp
“Begin with the end in mind”
– Steven Covey
Phil Ricci heads up Agile-Now, a recently formed
consulting firm specializing in deep dive, total
immersion agile experiences for small to medium
teams and works as a Scrum Master for the
Glynlyon corporation. An agile and project
management practitioner for more than fifteen
years, Phil has implemented a variety of flavors
of agile technology across software, education, training, and
product development. He has developed full training curriculum
for companies preparing to make the transition to the agile world.
Phil holds a Masters degree in Human Development,
PMI-ACP, CSP, and CSM Phil.ricci@agile-now.com
Your presenter
2. 6/2/2015
2
The starting point matters
The conversation is
the single greatest
source of
information about
what we create
but…
where we start matters!
How to sharpen
Have a great description
Assure clarity of user roles
Don’t contradict each other
Have “spot on” acceptance criteria
Be INVESTed wisely
Be sure you have only one story
3. 6/2/2015
3
User Stories
are about
Who
What
Why
A reminder
…and of course knowing how to tell we got it right!
User Story Life Cycle
Large
Unknowns
Small
Investable
Emerging
Details
Clear
Acceptance
Test
WIP
Done
Approaching
execution
Backlog
queen
4. 6/2/2015
4
Feasible
Usable
Valuable
Three quick questions to ask about
stories
Review description
dih-skrip-shuh
Characterization
Narrative
Portrayal
Declaration
Start by writing the title
Titles should be of sufficient detail to allow those
on the team to differentiate between titles of
other stories.
How descriptive is it?
How long is it?
Does the description match the title?
5. 6/2/2015
5
Clarify user role
Start with Personas
Review Roles
What don’t you know about your users?
Can you map each role in a story
klar-uh-fahy
Interpret
Define
Formulate
Analyze
Lynn
Hobbies
Family
Dislikes
Likes
Work
IT
UI/UX
Skiing
Snow
boarding
Hot
weather
Ice Cream
Milk ShakesDaughter
High School
Son
4th gradeWrestling
Meeting
new people
Trashy
novels
Movies
Swimming
Diving
Wine
Public
Speaking
Get “inside the head” of your Personas
Persona Mind Map
6. 6/2/2015
6
All
Most
Persona 1
Persona 4
Persona 5
Persona 6
Persona 2
Persona 3
◊◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊
◊◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊
◊ ◊ ◊ ◊ ◊ ◊ ◊ ◊
◊ ◊ ◊ ◊ ◊ ◊ ◊
◊ ◊ ◊ ◊ ◊ ◊ ◊
◊ ◊ ◊ ◊ ◊ ◊
◊ ◊ ◊ ◊ ◊ ◊
◊◊ ◊ ◊ ◊
Persona Matrix
What do your persona’s share in common with each other
Find commonalities among
personas in order to magnify
their use
Check for discrepancies
disˈkrepənsē/
Disagreement
Divergence
Variance
Difference
Do your stories “match”
Can you find a “rhythm” to your stories
Have you applied story mapping
7. 6/2/2015
7
Tech
Support
Sys
Admin
Curriculum
Mgt.
Student Instructor
School
Admin
Admin
Support
Base
Curriculum
Student Interface
Admin
Module
Curriculum
Rendering
Projects
Support
HTML 5
Support
New
Student UI
Create
Admin tool
admin user
Delete hard
code accts.
from adm
tool
Create
logging in
admin tool
Introduce
MathJax to
render
equations
Enable
Periodic
table
rendering
Implement
HTML 5
framwork
Add
support for
HTML 5
games
Update
Monarch to
handle
HTML5
animation
Allow
question
sorting
Allow
Matching
questions
Warn
students
when they
answer
question
Allow
expanded
project
time span
Allow
changing
project
time span
Display
project on
Home/sch.
Page
Regenerate
due dates
evenly over
school days
Display
lessons in
reverse
order
Allow verse
rendering
Allow verse
rendering
Support
tagging for
office video
Personas
Biz goals
User Activities
Story mapping
Critically review acceptance criteria
Are your Acceptance Criteria at relatively high level
Do your Acceptance Criteria suggest intent
Are your Acceptance Criteria independent from implementation
Have you addressed performance
Are usability issues impacted
Have you addressed what the story must do
Is error handling touched on
8. 6/2/2015
8
Be explicit
“The system will display the date.” …
In what format? Is “2010, October 1st”
acceptable?
Critically review acceptance criteria
N
V
I
E
S
T
Independent
Negotiable
Valuable
Estimable
Small
Testable
Invest sensibly
Compliments to Bill Wake: 2003
9. 6/2/2015
9
Too Small
Too Big
Just Right
Looking for the
Goldilocks story
Too Big
Is it really just one story
Difficult to estimate
Difficult to understand
Risky
Take too long to finish
They are Blurry
10. 6/2/2015
10
Splitting stories
Many ways to split stories
Places/methods to consider
splitting large stories
• At C.R.U.D boundaries
• At system boundaries where two systems interface
• By process – do part first
• Generic descriptors
• Decision trees
• Work flow
• Timeframe analysis
• Business rules
• Best possible outcome
11. 6/2/2015
11
Splitting stories: at CRUD
boundaries:
• This solution is commonly used in environments that
interact with a database
Splitting stories : at system
boundaries
• This solution is most often used in environments
where there are a large number of legacy
systems
12. 6/2/2015
12
Separate out: complex processes
• Perhaps a single entry
screen is composed of
multiple groups of
functionality
• Separate those out
Perhaps these
three areas of this
screen may be
separated into
separate stories
Splitting stories: generic descriptors
• Look for words/phrases in
stories that are not specific:
13. 6/2/2015
13
Splitting stories: decision trees
• Decision trees display logic and/or business
actions
• Perhaps you may collapse and focus on a
particular node of the tree
Splitting stories: work flow
• In the event that the story involves a less than
trivial workflow each individual workflow step
can be attached as an individual story
14. 6/2/2015
14
Splitting stories: time frame
analysis
Review what would happen if the story was
already implemented, what steps will be taken
with the functionality?
Splitting stories: business rules
Review what would happen if all business rules
were not implemented at the same time? Are
all the rules necessary immediately?
15. 6/2/2015
15
Splitting stories: best outcome possible
• Deal with the most probable (hopefully best)
outcome
Summary
Are your stories Usable, Valuable and Feasible
Taking your stories from fuzzy to razor sharp required diligence
during the full useful lifespan of the project
Are your user roles fully explored and
understood
Have you flushed out discrepancies between
stories
Does your acceptance criteria really match what
is required
Are your stories “right sized”
Are your stories fully “INVESTed”