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