User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Project Management Institute Kansas City Mid America

1. User Stories in an Agile EnvironmentMike McLaughlin, PMP, CSM, CSPProject Management InstituteKansas City Mid America ChapterMarch 19, 2012

2. Agenda • A Quick Agile/Scrum Overview • What is a User Story? • How do we write them? • Why do we write them? • A few addt’l tips • Conclusion/Sources/Q&A

3. How Does Agile Work?

4. What is a User Story? • A short, simple description of a feature told from the perspective of the person who desires the new capability. • Composed of 3 aspects: • Card • Conversation • Confirmation

5. User Story Format User story format As a ________, I want to ________________ ROLE PERFORM AN ACTION So I can ______________________. ACHIEVE A RESULT Why ROLE? So we can develop role-based capabilities Why ACTION? So we can agree on the expected capability Why RESULT? So we can separate BENEFIT from PREFERENCE

6. Sample Stories As a Business Traveler, I want to book flights by duration so I can travel conveniently. As an Approving Manager I want to see all expenses for one employee and one trip so I can approve expenses easily. As a Travel Coordinator, I want to see many flight options on one screen so I can help our customers select a flight. As a Billable Resource I want to see all my expenses for one trip so I can book the client accordingly.

7. Writing Good User Stories

8. Writing Stories • Independent • User stories in the creation of a new job posting website… A company can pay for a job posting with a Visa card. A company can pay for a job posting with a MasterCard. A company can pay for a job posting with an American Express card.

9. Writing Stories • Negotiable • Reminder to have a conversation • Not a contract

10. Writing Stories • Negotiable cont’d • Don’t include all the details, but if some are known, include as annotations. A company can pay for a job posting with a credit card. Note: accept Visa, MasterCard, and American Express. Consider Discover.

11. Writing Stories • Negotiable cont’d • Don’t include too much detail, e.g. A company can pay for a job posting with a credit card. Note: accept Visa, MasterCard, and American Express. Consider Discover. On purchases over $100, ask for card ID number from back of card. The system can tell what type of card it is from the first two digits of the card number. The system can store a card number for future use. Collect the expiration month and date of the card.

12. Writing Stories • Negotiable cont’d - A revised story card… A company can pay for a job posting with a credit card Note: Will we accept Discover cards? Note for UI: Don’t have a field for card type (it can be derived from first 2 digits on the card) - Test cases on back of the card… Test with Visa, MasterCard and American Express (pass) Test with Diner’s Club (fail) Test with good, bad and missing card ID #’s Test with expired cards Test with over $100 and under $100

13. Writing Stories • Valuable - User stories should be valuable to the customer, users, and purchasers of whatever it is we’re building. What we want to avoid are stories that are only valued by developers. For example, avoid stories like… All connections to the database are through a connection pool. All error handling and logging is done through a set of common classes. - The best way to ensure that each story is valuable to the customer or users is to have the customer write the stories.

14. Writing Stories • Estimatable – developers must be able to estimate the size of a user story / amount of time it’ll take to turn it into working code. • 3 common reasons it may not be… 1. Developers lack domain knowledge 2. Developers lack technical knowledge 3. The story is too big (epic)

15. Writing Stories • Small A user can post her resume. actually means… - That a resume can include education, prior jobs, salary history, publications, presentations, community service, and an objective. - That users can mark resumes as inactive - That users can have multiple resumes - That users can edit resumes - That users can delete resumes

16. Writing Stories • Small cont’d - Or we can turn an epic into user stories that are too small, e.g. A job seeker can enter a date for each community service entry on a resume’. A job seeker can edit the date for each community service entry on a resume. A job seeker can enter a date range for each prior job on a resume. - Better solution is to group smaller stories, e.g. A user can create resumes, which include education, prior jobs, salary history, publications, presentations, community service, and an objective. A user can edit a resume. A user can delete a resume. A user can have multiple resumes. A user can activate and inactivate resumes.

17. Writing Stories • Small cont’d Complex stories, e.g. A company can pay for a job posting with a credit card None of the developers have ever done credit card processing before, so we split the stories. Investigate credit card processing over the web. (A spike) A user can pay with a credit card.

18. Writing Stories • Testable A successful test pass proves the story was successfully developed. How do we handle non-functional requirements? A user must never have to wait long for any screen to appear. Should be re-written to say… New screens appear within 2 seconds in 95% of all cases. Automate tests whenever possible.

19. Why Stories? • Stories emphasize verbal communication Entrécomes with choice of soup or salad and bread. The system should prominently display a warning message whenever the user enters invalid data. The user can enter a name. It can be 127 characters.

20. Why Stories? • Stories are the right size for planning • Nesting 4.6 The system shall allow a room to be reserved with a credit card. 4.6.1 The system shall accept Visa, MasterCard and American Express cards. 4.6.1.1. The system shall verify that the card has not expired 4.6.2 The system shall charge credit card the indicated rate for all nights of stay before reservation confirmed. 4.7 The system shall give the user a unique confirmation number.

21. Why Stories? • Stories work for iterative development If I’m just starting out on a project, I may write Epic stories like… ‘As a business user, I can compose and send email, so I can communicate with my colleagues and customers’ This might be fine for early planning, but later, I’ll split that story into a bunch of other stories, like… ‘A business user can compose an email message’ ‘A business user can include graphics in email messages’ ‘A business user can send email messages’ ‘A business user can schedule an email to be sent at a specific time’

22. Why Stories? • Stories support opportunistic development Why top down solutions don’t work: • Users and customer do not generally know exactly what they want. • Even if the developers know all the requirements, many of the details they need to develop become clear only as they develop the system. • Even if the details are known up front, humans are incapable of comprehending that many details. • Even if we understand all the details, product and project changes occur. • People make mistakes Stories provide a solution… • that’s not reliant on users fully knowing and communicating their exact needs in advance • that’s not reliant on developers being able to fully comprehend a vast array of details • that embraces change

23. Why Stories? • Stories encourage ‘participatory design’

24. Why Stories? • Stories build up tacit knowledge

25. Gathering User Stories • Elicit & Capture • Techniques (just 2 of many) • User Story Writing Workshops • Prototypes

26. User Story Writing Workshops • Includes developers, users, the Product Owner, and SME’s. • Write as many stories as you can, rapidly. • Brainstorming + Prototyping

27. User Story Writing Workshops, cont’d Brainstorming + Prototyping – cont’d 1. Start with the roles. 2. Draw an empty box and tell the folks that it’s the main screen of the software. 3. Ask them what the selected user role can do from there. 4. The folks will start throwing out ideas about what actions the role can take. 5. For each action, draw a line to a new box, label that box, and write a story. e.g. creating a job posting site (think Careerbuilder.com, et al) Home page (boxes/diagram) Hot jobs Ads (job hunting tips) - leads to Post Resume (resume’ data fields) Employer Entrance (account info) – leads to Post Jobs (job desc fields); Review Applicants (list of applicants) Search Jobs – search fields – leads to Job Results (list of matching jobs) Review Applicants – leads to Resume View (all resume data) Job Results – leads to Job Details (all job information)

28. Paper or Plastic? • 3x5 index cards, post it notes, scrum boards, or software system? • Collocated teams or not?

29. UI • Keep the UI out of your stories as long as possible • Example: ‘Print dialog allows the user to edit the printer list. The user can add or remove printers from the printer list. The user can add printers either by auto-search or manually specifying the printer DNS name or IP address.’ • Recommended approach for designing UI in Agile: • Gather your stories / User Story Writing Workshop • Prioritize & organize your stories • Draw prototypes • Show to users / Refine as needed

30. Bugs • Bugs as stories

31. Conclusion • Agile methodology / Scrum Overview • User Stories – what, why, how • More information

32. Sources • ‘User Stories Applied – For Agile Software Development’ by Mike Cohn

33. Questions?

34. User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSPConsultant, AdamsGabbert