Agile gathering + guidelines stories

1,863 views

Published on

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.

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,863
On SlideShare
0
From Embeds
0
Number of Embeds
243
Actions
Shares
0
Downloads
21
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile gathering + guidelines stories

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. 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!! http://www.quora.com/Dropbox/Why-is-Dropbox-more-popular-than-other-tools-with-similar-functionality
  11. 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 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 http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/UseCasesDualScreen
  12. 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 detailsRef: Ch2. Writing Stories, http://fungsiong.blogspot.com/2011/06/agile.html

×