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
Jan 13, 2015
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
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
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)
• Key to ask~ Open-Ended & Context-Free Questions
Just answer
yes or no
(closed-ended)
More in-depth opinions, can answer in a variety of directions
The questions
implied answer or
preference
Not include any hint to imply
Elicit stories - techniques
Questionnaires Observation
watch
• Gather info. About stories
you already have
– Have a large number of
users
– Want to know what trend
– Collecting might time-lag
• Ask: not using some
feature more? …
• May wait one or several
iterations
• On-line questionnaires
may well !!
– One-way communication
• Observing users interact
with your software is a
good way
– Avoid your software build
exactly, but it’s not user
want
– Get the rapid and direct
feedback
– Join time: as early and
often as possible
– Track the decisions made
by user
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
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
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
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
Size the story to the horizon
Create a job-application website
• A Job Seeker can post a
resume
• A Job Seeker can search job
openings
• A Recruiter can post a job
opening
• A Recruiter can search
resumes
1st iteration – the highest level
Talk with customers
• A Job Seeker can add a new resume to the site.
– Constraint: Up to 50 concurrent users
• A Job Seeker can edit a resume that is already on the site.
• A Job Seeker can remove her resume from the site.
• A Job Seeker can mark a resume as inactive.
• A Job Seeker can mark a resume as hidden from certain employers.
• A Job Seeker can see how many times her resume has been viewed.
• … and so on about posting resumes…
• A Job Seeker can search job openings.
• A Recruiter can post job openings.
• A Recruiter can search resumes.
Horizon-
expanding
(Slice the
cake by
technical
lines)
A closed
stories
• Keep UI out as possible: Make new
functionality(after stories shift) can
modify or extend the existing
functions
• keep a flexible format when time
goes
Key method:
2nd iteration
Real case about simplify function Win!! Syncplicity Dropbox
Start around Spring
of 2008
First release about
Sep. 2008
Invite a friend,
earned 1G (space)
Win!!
Invite a friend, earned
250MB
More than one
folder (complex =>
maintain cost more
time)
Just one folder (simple
=> easy to maintain)
Spend much time to
fix bug
(Ex. C:\winsows\ for
dozens of users
~>.<~)
Coach their customers
what necessary
features
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
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
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/UseCasesDualScreen
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.
Home Network TF discussion – Use Case Dual Screen
Use Case: dual screen time-synchronised content
Submitter(s): BBC (Matt Hammond)
Description: …. (scenario including all actors)
Need/justification: …
Dependencies: none
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