Introduce gathering stories technologies as user interview, questionnaires, observation & story-writing workshops. Share some guidelines and real cases about to make good stories as size the story to the horizon & including user roles in the stories.

1. User Stories Applied:
For Agile Software Development
–
Ch 4. Gathering Stories &
Ch 7. Guidelines for Good Stories
Chen Jing Fung @iii
2011/6/14
Reference: Ch2. Writing Stories,
http://fungsiong.blogspot.com/2011/06/agile.html

2. How to gather stories
• Problem: elicit & capture all requirements
(user real needs) are very difficult !!
– Solution: ask the right types of questions
• A little is enough. (the advantage of Agile)
• After several iterations, will gather whole picture of
customer real needs.
– Techniques
• User interviews
• Questionnaires
• Observation
• Story-writing workshops

3. User interviews
• Interview real user whenever possible!!
– Working with user proxies (ch.5)
• Task force as a sounding-board for ideas
• Proxies remains the project’s final decision-maker
– But!! Most users don’t know what their true needs
– These channels can get user responses by the
formulate questions
• Via phone, email, interactive voice response or visual
survey design tool(can dragging & dropping icons)
More in-depth opinions, can answer in a variety of directions
• Key to ask~ Open-Ended & Context-Free Questions
Just answer The questions
yes or no implied answer or Not include any hint to imply
(closed-ended) preference

4. Elicit stories - techniques
watch
Questionnaires Observation
• Gather info. About stories • Observing users interact
you already have with your software is a
– Have a large number of good way
users – Avoid your software build
– Want to know what trend exactly, but it’s not user
– Collecting might time-lag want
• Ask: not using some – Get the rapid and direct
feature more? … feedback
• May wait one or several – Join time: as early and
iterations often as possible
• On-line questionnaires
– Track the decisions made
may well !!
by user
– One-way communication

5. Story-writing workshops
• A well method to gather many stories at different level
• Roles?
– Hold a meeting including developers, users, the product
customer & other parties by writing stories
• Condition?
– No priorities are associated with the stories
• Tools? => low-fidelity prototyping (easy change)
– Paper, noted cards or white board => maps very high level
iterations
• Decide which system user role you’d like… (change your role do
again..)
– Make component’s title => a depth-first approach (vertical extending)
– Link indicates => breadth-first approach (horizontal links)
• Revisit prototyping stories will append some missing parts
• Note: user stories in as short a time as possible

6. Summary
• Eliciting & capturing all user requirement is difficult
– User may not know their real want
– Captured & locked : unchanged
• Capture different sizes of requirements is good
– Requirement may change over time
• User stories can be found by interviewing users, observing
user, questionnaires, & holding story-writing workshops
• Using a combination of methods > just one method
– Avoid loss
• The useful answers are from open-ended, context-free
questions
– Tell me about how you’d like to search for a job > Will you
search for a job by title
imply

7. Chapter 7. Guidelines for Good
Stories
How to gather for write stories
How to identify key user roles &
the roles of acceptance testing
Reference: Ch2. Writing Stories,
http://fungsiong.blogspot.com/2011/06/agile.html

8. Some Guidelines for good stories
• Size the story to the horizon
– Slice the cake
– Put constraints on cards
– Write closed stories
– Keep the UI out as long as possible
– Some things aren’t stories
• Keep a flexible format
• Including user roles in the stories
– Write for one user => easy to split
– Write in active voice
– Customer writes
• Summary

9. Size the story to the horizon A closed
2nd iteration stories
Create a job-application website • A Job Seeker can add a new
resume to the site.
Talk with customers – Constraint: Up to 50 concurrent users
• A Job Seeker can edit a resume that
1st iteration – the highest level is already on the site.
• A Job Seeker can post a • A Job Seeker can remove her
resume resume from the site.
Horizon- • A Job Seeker can mark a resume as
• A Job Seeker can search job
expanding inactive.
openings
• A Recruiter can post a job
• A Job Seeker can mark a resume as
(Slice the hidden from certain employers.
opening cake by • A Job Seeker can see how many
• A Recruiter can search technical times her resume has been viewed.
resumes lines) • … and so on about posting
Key method: resumes…
• Keep UI out as possible: Make new
functionality(after stories shift) can • A Job Seeker can search job
openings.
modify or extend the existing
functions • A Recruiter can post job openings.
• keep a flexible format when time • A Recruiter can search resumes.
goes

10. Real case about simplify function Win!!
Syncplicity Dropbox
Start around Spring First release about
of 2008 Sep. 2008
Invite a friend, Invite a friend, earned
earned 1G (space) 250MB
Win!!
More than one Just one folder (simple
folder (complex => => easy to maintain)
maintain cost more
time)
Spend much time to Coach their customers
fix bug what necessary
(Ex. C:winsows for features
dozens of users
~>.<~) Change the
requirement if it works
for 80% customer
Continual Growth
(2008-2011) win!!
http://www.quora.com/Dropbox/Why-is-Dropbox-more-popular-than-other-tools-with-similar-functionality

11. Including user roles in the stories
• The format:
– I as a (role) want (function) so that (business value)
• Design key:
List all actors(don’t forget the purpose), write for one user (more
specific), write in active voice, customer writes
Home Network TF discussion – Use Case Dual Screen
Actors/Entities:
1. A programme or content comprises a television programme or other piece of audio visual
content.
2. A television is a device that presents programme content from a variety of source - such as
received via broadcast (cable, satellite, terrestrial), on-demand streaming services, or
streamed from other devices in the home (e.g. PVR). It is connected to the home network.
3. A companion device could be a laptop, tablet, mobile phone or other device in the
possession of the user. It is connected to the home network.
4. A website comprises web pages served from Internet servers belonging to broadcasters,
content providers or any other third party.
Use Case: dual screen time-synchronised content
Submitter(s): BBC (Matt Hammond)
Description: …. (scenario including all actors)
Need/justification: …
Dependencies: none
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/UseCasesDualScreen

12. Summary
• To identify stories, start by considering the goal of
each user role
• When splitting a story, try to come up with stories
– Cut through all layers of applications
– Consider new functionality can modify or extend the
existing functions
– Write a specific story (user feels justified)
– Create constraint cards (testable)
– Keep user stories short & don’t forget the purpose
• 1st iteration may write high-level stories (future can extend)
• Augment(/gather) stories with other requirement if necessary
– Include the user role
– Write stories in active voice
• Customer > developer write the stories
• Don’t number story cards
– Keep the user interface out of the stories for as long as
possible => not include all details
Ref: Ch2. Writing Stories, http://fungsiong.blogspot.com/2011/06/agile.html