The document explains the importance of user stories in software development, emphasizing their role in improving communication between developers and businesses, and addressing issues like feature prioritization and scope changes. It outlines what constitutes a good user story, including characteristics like being independent, negotiable, valuable, estimable, small, and testable, while also providing a template for writing them. Additionally, it clarifies what are not considered stories and encourages focus on conversation rather than extensive documentation.

1. User Stories- Sunil Kumar

2. AgendaWhat is the need for user stories?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

3. What problems do user stories address?(mis)Communication!

4. Between?Those who want the softwareThose who build the software

5. Balance is critical

6. Business side dominates?

7. Developers dominate?

8. Resource allocationNeed to work together to make it a shared problem.

9. Developers Responsibility of resource allocation!May trade quality for additional featuresMay only partially implement the featureMay solely take decisions that should involve business side

10. Only business shoulders the responsibilityLengthy upfront requirements negotiation and signoffFeatures are dropped as the deadline nears

11. We cannot predict a software schedule!

12. As users see software, they come up with new ideas

13. Too many intangibles!

14. Developers have hard time estimating!

15. So what do we do?

16. Make decisions on information often

17. Spread the decision-making across the project

18. This is where user stories come in

19. What are stories? 3C

20. Story CardWritten on Note cardsShould have estimates, notes etcNo jargonWritten in direct speech

21. Conversation!Details behind the storyEmerges when team talks with Product owner, customer / customer proxy

22. ConfirmationAcceptance tests

23. Example of StoryA user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted

24. A user can view information about each job that is matched by a search

25. A user can view detailed information about a company that has posted a jobMore Samples!

26. Conversation?

28. What is an Epic?A user can search for a jobA company can post job openings

29. Theme?

30. Why write Stories?

31. Words are imprecise!Main dish comes with soup or salad and bread(Soup or salad) and Bread?(Soup) or (Salad and bread)?The User can enter a name. it can be 127 charactersMust the user enter a name?Can it be other than 127 chars?

32. Words are imprecise contd…The system should prominently display a warning message whenever the user enter invalid dataWhat does should mean?What does prominently display mean?Is invalid data defined elsewhere?

33. Stories shift the focus from writing to talking“You built what I asked for, but it’s not what I need”

34. Stories are equally understandable by developers and customers

35. Support iterative development

36. Stories are right size for planning

37. Stories support participatory design

38. Stories emphasize user’s goals not system attributesWhat are we building?The product shall have a gas engineThe product shall have four wheelsThe product shall have rubber tyre mounted to each wheelThe product shall have a steering wheelThe product shall have a steel body

39. What if we had stories instead?

40. Don’t forget the purposeThe story text we write on cards is less important than the conversations we have

41. User Story Template“As a <Some Role>I want <Some Need>So that <Some Benefit>”

42. A “real” Story cardAs an <unregistered user of [an online game]> I want <to setup a trial team>So that <I can try the game without signing up>

43. Advantages of “As a user, I want” user story templateWith “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.Helps in prioritizing story. The product owner is forced to understand the feature, benefits and value (“so that” phrase)This format is a best practice towards executable requirements and a domain specific language

44. What is criteria for good story?IndependentNegotiableValuable to users or customersEstimableSmallTestable

45. IndependentIntroduce as little dependencies as possibleBreak up work in vertical layersDependent stories should not be done in same sprint

46. IndependentBAD

47. Company can pay for a job posting with a visa card

48. Company can pay for a job posting with a master card

49. Company can pay for a job posting with an American Express

50. Good

51. Company can pay for a job posting with a credit card

52. Also good

53. Company can pay for a job posting with one type of a credit card

54. Company can pay for a job posting with two additional types of credit cardsNegotiableNot contractsDescribe what, not howShould be imprecise and open for negotiationShould encourage conversationNot requirements, leads to requirements

55. ValuableIf we can’t specify value of a story we probably don’t know enough about it

56. Valuable to purchasers or usersThroughout the development process, the development team will produce documentation suitable for an ISO 9001 audit. -- purchaser

57. Not

58. All connections to the database are through a connection pool

59. All error handling and logging is done through a set of common classes.

60. If there’s a technical story put it in terms the business can understand

61. Up to fifty users should be able to use the application with a five-user database license

62. All errors are presented to the user and logged in a consistent manner.Estimable*“Make login button look ‘cool’” is not estimableIf we can’t estimate a story we cant commit to itLack domain knowledge

63. Lack technical knowledge

64. Story is too big* Yes, it is a word!

65. SmallSize does matterA user can plan a vacation (EPIC)Based on team and capabilities and technology in use.Allows more granular tracking of progressEasier to estimate (less error prone)

66. TestableIf you can’t test it, how do you knowIt’s done?It’s done right?Should have done criteriaBusiness criteriaTechnical DebtCross-cutting concernsRegression failures allowable?