This document discusses techniques for gathering user stories in agile software development, emphasizing the challenges of capturing true user needs and the importance of utilizing a combination of methods such as interviews, questionnaires, and workshops. It also outlines guidelines for writing effective user stories, such as sizing them appropriately, focusing on one user role, and keeping the user interface considerations out until necessary. The document stresses the importance of collaboration and the iterative nature of gathering and refining requirements over time.

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