Agile gathering + guidelines stories
Upcoming SlideShare
Loading in...5

Agile gathering + guidelines stories



Introduce gathering stories technologies as user interview, questionnaires, observation & story-writing workshops. ...

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.



Total Views
Views on SlideShare
Embed Views



6 Embeds 225 189 29 3 2 1 1


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Agile gathering + guidelines stories Agile gathering + guidelines stories Presentation Transcript

  • 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,
  • 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) 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
  • 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
  • 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,
  • 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 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
  • Real case about simplify function Win!!Syncplicity DropboxStart around Spring First release aboutof 2008 Sep. 2008Invite a friend, Invite a friend, earnedearned 1G (space) 250MBWin!!More than one Just one folder (simplefolder (complex => => easy to maintain)maintain cost moretime)Spend much time to Coach their customersfix bug what necessary(Ex. C:winsows for featuresdozens of users~>.<~) Change the requirement if it works for 80% customer Continual Growth (2008-2011) win!!
  • 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 writesHome Network TF discussion – Use Case Dual ScreenActors/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
  • 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 detailsRef: Ch2. Writing Stories,