1. User Stories- 2 Advanced Software Engineering 603 492 Dr Nuha El-Khalili

2. User Stories – 3C’s Card: – Written description of the story, used for planning and as a reminder Conversation: – Conversations about the story that serve to collect the details of the story Confirmation: – Tests that convey and document details that can be used to determine when a story is complete

3. Traditional Requirements IEEE 830–style software requirements specification is the use of the phrase “The system shall…” 300 pages of requirements, no one will read it Impossible for a reader to grasp the big picture. Written language is often very imprecise You have to estimate how difficult or time– consuming it will be to develop

4. Traditional Requirements - Imprecise IEEE 830 documents are a list of requirements, stories describe user’s goals For example, consider the following requirements: – 3.4) The product shall have a gasoline-powered engine. – 3.5) The product shall have four wheels. – 3.5.1) The product shall have a rubber tire mounted to each wheel. – 3.6) The product shall have a steering wheel. – 3.7) The product shall have a steel body. Customer goals for the product: – The product makes it easy and fast for me to mow my lawn. – I am comfortable while using the product.

5. Traditional Requirement- Cost Typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. This document is then handed to the programmers, who tell the analysts that the project will take 24 months, rather than the six months they estimated. In this case, time was wasted writing the three-fourths of the document that the team won't have time to develop. And more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time

6. Use Cases vs. Stories Scope: Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size Level of completeness: James Grenning has noted that the text on a story card plus acceptance tests “are basically the same thing as a use case.” By this, Grenning means that the story corresponds to the use case’s main success scenario, and that the story’s tests correspond to the extensions of the use case. One use case brief will typically tell more than one story

7. Use Cases vs. Stories Purpose – Use cases document an agreement between the customer and the developers – User stories are reminders to have a conversations and are written to facilitate planning

8. Example

10. Acceptance test cases for the story: “A Recruiter can pay for a job posting with a credit card” – Test with Visa, MasterCard, and American Express (pass) – Test with Diner's Club (fail) – Test with good, bad, and missing card ID numbers – Test with expired cards – Test with different purchase amounts (including one over the card’s limit)

11. On a large project there can be lots of stories – Solution is to remember to keep some as epics initially Or “staple” some together into themes Stories on cards don’t facilitate traceability – But you can do it, or you can use software Stories focus on increasing tacit, not formal, communication – May need to supplement with some formal documentation Drawbacks

12. Use stories with other written documentation – Business rules – Data dictionaries – Use cases – Examples of inputs and expected result Drawbacks

13. 1.Brainstorm an initial set of user stories 2.Organize the initial set – Arrange cards spatially to indicate overlapping and similar roles – Use any arrangement rules you want 3.Discuss what is meant by each card 4.Look for cards to – Combine – Replace with a more generic/different card – Eliminate cards that are unimportant to the success of the product During a Story Workshop

14. Techniques for gathering stories

15. What makes a good story?

16. Avoid introducing dependencies Leads to difficulty prioritizing and planning Independent

17. Stories are not – Written contracts – Requirements the software must fulfill Do not need to include all details Too many details give the impressions of – false precision or completeness – that there’s no need to talk further Need some flexibility so that we can adjust how much of the story gets implemented Negotiable

18. Stories must be valuable to either: Should be rewritten to show the benefit Valuable

19. Small stories for the near future Epics for further out Large stories (epics) are – Hard to estimate – Hard to plan – Won’t fit in a single iteration Two types of large story – Complex story – Compound story Sized appropriately

20. A story that is inherently large and cannot easily be disaggregated into constituent stories Very rare Some stories look complex because we don’t know enough Use a spike in those situations – First iteration: acquire knowledge – Second iteration: do the work Complex stories

21. An epic that comprises multiple shorter stories Often hide a great number of assumptions Compound stories

22. Splitting a compound story

24. Because stories are used in planning A story may not be estimatable if Estimatable

25. Tests demonstrate that a story meets the customer’s expectations Testable