User stories applied ch4


Published on

Gathering Stories

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User stories applied ch4

  2. 2. Trawling: the process of gatheringrequirements Different-sized nets can be used to capture different-sized requirements The idea that requirements, like fish, mature and possibly die. You wont catch all of the fish in an area by trawling A skilled requirements trawler will know where to look for requirements
  3. 3. The key difference betweenWaterfall and Agile Gathering Requirement process  Waterfall  emphasis on getting all the requirements right and written early in the project  Agile  acknowledge that it is impossible to get all of the user stories in one pass
  4. 4. One of the advantages ofworking with stories is that it is very easy to write them at different levels of detail.
  5. 5. Even though we acknowledge the impossibility of writing all of the stories for a project.
  6. 6. We should still make an initialupfront attempt to write those that we can,even if many are written at a very high level
  7. 7. We can then evolve that story intosmaller, more useful stories later.
  8. 8. Techniques of gatheringrequirements User interviews Questionnaires Observation Story-writing workshops
  9. 9. User interviews One of the keys to success with interviews is the selection of interviewees The best technique for getting to the essence of a users needs is through the questions you ask.
  10. 10. Open-Ended and Context-FreeQuestions give no room for anything other than a simple yes or no do not include an implied answer or preference
  11. 11. Questionnaires It is useful for a large user population. Questionnaires do not lend themselves to follow up questions
  12. 12. Disadv If you give the user a list of choices, then you may miss hearing about the features youve never thought of. Alternatively, if the user is allowed to respond with free-form text it will be difficult to tabulate answers.
  13. 13. Observation You can learn a lot from observing someone using my software Unfortunately, opportunities for user observation are rare  unless you are developing for in-house customers.
  14. 14. Story-writing workshops We need different kinds of participants to attend this meeting Participants write as many stories as they can No priorities are associated with the stories at this point  the customer will have a chance to do that later
  15. 15. A good story-writing workshop Combines the best elements of brainstorming with low-fidelity prototyping  paper, note cards, or a white board The prototype is built up iteratively Not to identify actual screens and fields Rather, the conceptual workflows are identified
  16. 16. A low-fidelity prototype forBigMoneyJobs
  17. 17. Process Identify one user role or persona first Draw the empty box and tell the participants that it’s the main screen Ask them what they can do here (action) For each action, draw a line to a new box, label that box, and write a story. Repeat the process using each role or persona so the order does not matter
  18. 18. Throw It Away Be sure to throw away or erase the low-fidelity prototype within a few days of creating it. A prototype is not a long-term artifact of your development process You dont want to cause any confusion by keeping it around.
  19. 19. During a story writing workshop the focusshould be on quantity rather than quality.
  20. 20. Even if youll eventually keepyour stories electronically, during the story-writing workshop use cards.
  21. 21. You do not want to get boggeddown in lengthy debate over each story. If a story is redundant with or becomes replaced by a betterstory later, then you can just rip up the story.