Presentation is loading. Please wait.

Presentation is loading. Please wait.

User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Project Management Institute Kansas City Mid America Chapter March 19, 2012.

Similar presentations


Presentation on theme: "User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Project Management Institute Kansas City Mid America Chapter March 19, 2012."— Presentation transcript:

1 User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Project Management Institute Kansas City Mid America Chapter March 19, 2012

2 AdamsGabbert Proprietary 2 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 AdamsGabbert Proprietary 3 How Does Agile Work?

4 AdamsGabbert Proprietary 4 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 AdamsGabbert Proprietary 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 5

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

7 AdamsGabbert Proprietary 7 7 Writing Good User Stories 7

8 AdamsGabbert Proprietary 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. 8

9 AdamsGabbert Proprietary 9 Writing Stories Negotiable – Reminder to have a conversation – Not a contract 9

10 AdamsGabbert Proprietary 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. 10

11 AdamsGabbert Proprietary 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. 11

12 AdamsGabbert Proprietary 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 12

13 AdamsGabbert Proprietary 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. 13

14 AdamsGabbert Proprietary 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) 14

15 AdamsGabbert Proprietary 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 15

16 AdamsGabbert Proprietary 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. 16

17 AdamsGabbert Proprietary 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. 17

18 AdamsGabbert Proprietary 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. 18

19 AdamsGabbert Proprietary 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. 19

20 AdamsGabbert Proprietary 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. 20

21 AdamsGabbert Proprietary 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’ 21

22 AdamsGabbert Proprietary 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 22

23 AdamsGabbert Proprietary 23 Why Stories? Stories encourage ‘participatory design’ 23

24 AdamsGabbert Proprietary 24 Why Stories? Stories build up tacit knowledge 24

25 AdamsGabbert Proprietary 25 Gathering User Stories Elicit & Capture Techniques (just 2 of many) – User Story Writing Workshops – Prototypes

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

27 AdamsGabbert Proprietary 27 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) User Story Writing Workshops, cont’d 27

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

29 AdamsGabbert Proprietary 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 AdamsGabbert Proprietary 30 Bugs Bugs as stories

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

32 AdamsGabbert Proprietary 32 Sources ‘User Stories Applied – For Agile Software Development’ by Mike Cohn

33 AdamsGabbert Proprietary 33 Questions?

34 User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Consultant, AdamsGabbert


Download ppt "User Stories in an Agile Environment Mike McLaughlin, PMP, CSM, CSP Project Management Institute Kansas City Mid America Chapter March 19, 2012."

Similar presentations


Ads by Google