Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
User Stories<br />- Sunil Kumar<br />
Agenda<br />What is the need for user stories?<br />What is a story?<br />Why story?<br />What is criteria for a good stor...
What problems do user stories address?<br />(mis)Communication!<br />
Between?<br />Those who want the software<br />Those who build the software<br />
Balance is critical<br />
Business side dominates?<br />
Developers dominate?<br />
Resource allocation<br />Need to work together to make it a shared problem.<br />
Developers Responsibility of resource allocation!<br />May trade quality for additional features<br />May only partially i...
Only business shoulders the responsibility<br />Lengthy upfront requirements negotiation and signoff<br />Features are dro...
We cannot predict a software schedule!<br />
As users see software, they come up with new ideas<br />
Too many intangibles!<br />
Developers have hard time estimating!<br />
So what do we do?<br />
Make decisions on information often<br />
Spread the decision-making across the project<br />
This is where user stories come in<br />
What are stories? 3C<br />
Story Card<br />Written on Note cards<br />Should have estimates, notes etc<br />No jargon<br />Written in direct speech<b...
Conversation!<br />Details behind the story<br />Emerges when team talks with Product owner, customer / customer proxy<br />
Confirmation<br />Acceptance tests<br />
Example of Story<br /><ul><li>A user can search for jobs by attributes like location, salary range, job title, company nam...
A user can view information about each job that is matched by a search
A user can view detailed information about a company that has posted a job</li></li></ul><li>More Samples!<br />
Conversation?<br />
What is an Epic?<br />A user can search for a job<br />A company can post job openings<br />
Theme?<br />
Why write Stories?<br />
Words are imprecise!<br />Main dish comes with soup or salad and bread<br />(Soup or salad) and Bread?<br />(Soup) or (Sal...
Words are imprecise contd…<br />The system should prominently display a warning message whenever the user enter invalid da...
Stories shift the focus from writing to talking<br />“You built what I asked for, but it’s not what I need”<br />
Stories are equally understandable by developers  and customers<br />
Support iterative development<br />
Stories are right size for planning<br />
Stories support participatory design<br />
Stories emphasize user’s goals not system attributes<br />What are we building?<br />The product shall have a gas engine<b...
What if we had stories instead?<br />
Don’t forget the purpose<br />The story text we write on cards is less important than the conversations we have<br />
User Story Template<br />“As a &lt;Some Role&gt;<br />I want &lt;Some Need&gt;<br />So that &lt;Some Benefit&gt;”<br />
A “real” Story card<br />As an &lt;unregistered user of <br />[an online game]&gt;<br />	I want &lt;to setup a trial team&...
Advantages of “As a user, I want” user story template<br />With “I want” phrase, person more closely identifies with stori...
What is criteria for good story?<br />Independent<br />Negotiable<br />Valuable to users or customers<br />Estimable<br />...
Independent<br />Introduce as little dependencies as possible<br />Break up work in vertical layers<br />Dependent stories...
Independent<br /><ul><li>BAD
Company can pay for a job posting with a visa  card
Company can pay for a job posting with a master card
Company can pay for a job posting with an American Express
Good
Company can pay for a job posting with a credit card
Also good
Company can pay for a job posting with one type of a credit card
Company can pay for a job posting with two additional types of credit cards</li></li></ul><li>Negotiable<br />Not contract...
Valuable<br />If we can’t specify value of a story we probably don’t know enough about it<br />
Valuable to purchasers or users<br /><ul><li>Throughout the development process, the development team will produce documen...
Not
All connections to the database are through a connection pool
All error handling and logging is done through a set of common classes.
If there’s a technical story put it in terms the business can understand
Up to fifty users should be able to use the application with a five-user database license
All errors are presented to the user and logged in a consistent manner.</li></li></ul><li>Estimable*<br />“Make login butt...
Lack technical knowledge
Story is too big</li></ul>* Yes, it is a word!<br />
Small<br />Size does matter<br />A user can plan a vacation (EPIC)<br />Based on team and capabilities and technology in u...
Testable<br />If you can’t test it, how do you know<br />It’s done?<br />It’s done right?<br />Should have done criteria<b...
Upcoming SlideShare
Loading in …5
×

User Story

8,931 views

Published on

This presentation describe
What is the need for user stories in Agile project?
What is a story?
Why story?
What is criteria for a good story?
What are not stories?

Prerequisite? Knowledge of Scrum and it’s terms

  • Be the first to comment

User Story

  1. 1. User Stories<br />- Sunil Kumar<br />
  2. 2. Agenda<br />What is the need for user stories?<br />What is a story?<br />Why story?<br />What is criteria for a good story?<br />What are not stories?<br />Prerequisite? Knowledge of Scrum and it’s terms<br />
  3. 3. What problems do user stories address?<br />(mis)Communication!<br />
  4. 4. Between?<br />Those who want the software<br />Those who build the software<br />
  5. 5. Balance is critical<br />
  6. 6. Business side dominates?<br />
  7. 7. Developers dominate?<br />
  8. 8. Resource allocation<br />Need to work together to make it a shared problem.<br />
  9. 9. Developers Responsibility of resource allocation!<br />May trade quality for additional features<br />May only partially implement the feature<br />May solely take decisions that should involve business side<br />
  10. 10. Only business shoulders the responsibility<br />Lengthy upfront requirements negotiation and signoff<br />Features are dropped as the deadline nears<br />
  11. 11. We cannot predict a software schedule!<br />
  12. 12. As users see software, they come up with new ideas<br />
  13. 13. Too many intangibles!<br />
  14. 14. Developers have hard time estimating!<br />
  15. 15. So what do we do?<br />
  16. 16. Make decisions on information often<br />
  17. 17. Spread the decision-making across the project<br />
  18. 18. This is where user stories come in<br />
  19. 19. What are stories? 3C<br />
  20. 20. Story Card<br />Written on Note cards<br />Should have estimates, notes etc<br />No jargon<br />Written in direct speech<br />
  21. 21. Conversation!<br />Details behind the story<br />Emerges when team talks with Product owner, customer / customer proxy<br />
  22. 22. Confirmation<br />Acceptance tests<br />
  23. 23. Example of Story<br /><ul><li>A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted
  24. 24. A user can view information about each job that is matched by a search
  25. 25. A user can view detailed information about a company that has posted a job</li></li></ul><li>More Samples!<br />
  26. 26. Conversation?<br />
  27. 27.
  28. 28. What is an Epic?<br />A user can search for a job<br />A company can post job openings<br />
  29. 29. Theme?<br />
  30. 30. Why write Stories?<br />
  31. 31. Words are imprecise!<br />Main dish comes with soup or salad and bread<br />(Soup or salad) and Bread?<br />(Soup) or (Salad and bread)?<br />The User can enter a name. it can be 127 characters<br />Must the user enter a name?<br />Can it be other than 127 chars?<br />
  32. 32. Words are imprecise contd…<br />The system should prominently display a warning message whenever the user enter invalid data<br />What does should mean?<br />What does prominently display mean?<br />Is invalid data defined elsewhere?<br />
  33. 33. Stories shift the focus from writing to talking<br />“You built what I asked for, but it’s not what I need”<br />
  34. 34. Stories are equally understandable by developers and customers<br />
  35. 35. Support iterative development<br />
  36. 36. Stories are right size for planning<br />
  37. 37. Stories support participatory design<br />
  38. 38. Stories emphasize user’s goals not system attributes<br />What are we building?<br />The product shall have a gas engine<br />The product shall have four wheels<br />The product shall have rubber tyre mounted to each wheel<br />The product shall have a steering wheel<br />The product shall have a steel body<br />
  39. 39. What if we had stories instead?<br />
  40. 40. Don’t forget the purpose<br />The story text we write on cards is less important than the conversations we have<br />
  41. 41. User Story Template<br />“As a &lt;Some Role&gt;<br />I want &lt;Some Need&gt;<br />So that &lt;Some Benefit&gt;”<br />
  42. 42. A “real” Story card<br />As an &lt;unregistered user of <br />[an online game]&gt;<br /> I want &lt;to setup a trial team&gt;<br />So that &lt;I can try the game without signing up&gt;<br />
  43. 43. Advantages of “As a user, I want” user story template<br />With “I want” phrase, person more closely identifies with stories and person’s mind goes instantly to imagining as he or she is such-and-such.<br />Helps in prioritizing story. The product owner is forced to understand the feature, benefits and value (“so that” phrase)<br />This format is a best practice towards executable requirements and a domain specific language<br />
  44. 44. What is criteria for good story?<br />Independent<br />Negotiable<br />Valuable to users or customers<br />Estimable<br />Small<br />Testable<br />
  45. 45. Independent<br />Introduce as little dependencies as possible<br />Break up work in vertical layers<br />Dependent stories should not be done in same sprint<br />
  46. 46. Independent<br /><ul><li>BAD
  47. 47. Company can pay for a job posting with a visa card
  48. 48. Company can pay for a job posting with a master card
  49. 49. Company can pay for a job posting with an American Express
  50. 50. Good
  51. 51. Company can pay for a job posting with a credit card
  52. 52. Also good
  53. 53. Company can pay for a job posting with one type of a credit card
  54. 54. Company can pay for a job posting with two additional types of credit cards</li></li></ul><li>Negotiable<br />Not contracts<br />Describe what, not how<br />Should be imprecise and open for negotiation<br />Should encourage conversation<br />Not requirements, leads to requirements<br />
  55. 55. Valuable<br />If we can’t specify value of a story we probably don’t know enough about it<br />
  56. 56. Valuable to purchasers or users<br /><ul><li>Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit. -- purchaser
  57. 57. Not
  58. 58. All connections to the database are through a connection pool
  59. 59. All error handling and logging is done through a set of common classes.
  60. 60. If there’s a technical story put it in terms the business can understand
  61. 61. Up to fifty users should be able to use the application with a five-user database license
  62. 62. All errors are presented to the user and logged in a consistent manner.</li></li></ul><li>Estimable*<br />“Make login button look ‘cool’” is not estimable<br />If we can’t estimate a story we cant commit to it<br /><ul><li>Lack domain knowledge
  63. 63. Lack technical knowledge
  64. 64. Story is too big</li></ul>* Yes, it is a word!<br />
  65. 65. Small<br />Size does matter<br />A user can plan a vacation (EPIC)<br />Based on team and capabilities and technology in use.<br />Allows more granular tracking of progress<br />Easier to estimate (less error prone)<br />
  66. 66. Testable<br />If you can’t test it, how do you know<br />It’s done?<br />It’s done right?<br />Should have done criteria<br />Business criteria<br />Technical Debt<br />Cross-cutting concerns<br />Regression failures allowable?<br />
  67. 67. Testable<br /><ul><li>User must find the software easy to use.
  68. 68. A novice user is able to complete common workflows without training
  69. 69. A user must not have to wait long for a screen to appear.
  70. 70. New screens appear within two seconds in 95% of all cases.
  71. 71. Strive for 99% automation
  72. 72. Automate on the code not just the UI.
  73. 73. Fit is good (Fitnesse)
  74. 74. NUnit is good</li></li></ul><li>What are not stories?<br />
  75. 75. Screen mockup (not story)<br />
  76. 76. Use case (not story)<br />
  77. 77. UML diagrams (not story)<br />
  78. 78. Specification (not story)<br />
  79. 79. Some guideline for story writing<br />
  80. 80. Include user roles in stories<br /><ul><li>as a (role) I want (function) because (business value)</li></li></ul><li>Write for one user<br /><ul><li>Job seeker can remove a resume
  81. 81. Job seeker can remove her own resume</li></li></ul><li>Write in active voice<br /><ul><li>Bad
  82. 82. A resume can be posted by a job seeker
  83. 83. Good
  84. 84. A job seeker can post a resume</li></li></ul><li>Customer writes the story<br /><ul><li>Not developer
  85. 85. But they can suggest
  86. 86. Which maybe is write them then get signoff
  87. 87. Offer advice
  88. 88. In the end the customer has to prioritize them so they need to know the language on the card fully.</li></li></ul><li>Don’t number the cards<br /><ul><li>Pointless over head
  89. 89. You’ll be shredding cards and creating cards often</li></li></ul><li>Don’t forget the purpose<br /><ul><li>Reminder about the requirements not the document of the requirements.
  90. 90. Don’t replace the conversation by adding the detail.</li></li></ul><li>References<br />http://www.mountaingoatsoftware.com/presentations/103-user-stories<br />http://www.slideshare.net/guest446c0/user-stories-1015064<br />http://www.danube.com/webinars<br />All images collected through google<br />
  91. 91. Questions?<br />

×