WRITING USER STORIES. presented by, Nicholas Cancelliere CSM/CSP.

Transcription

1 WRITING USER STORIES presented by, Nicholas Cancelliere CSM/CSP

2 Background Agile since 2003 HomeAway.com InCircuit Development Corp Involved in web development for over 11 years NTT Communications / Verio Certified Scrummaster (CSM) and Scrum Practitioner (CSP)

3 Personal Objectives What is your reason for attending today? Who are you? What organization do you work for? What is your role?

4 Before We Begin No electronics (unless it is an emergency) One conversation at a time Remember, we learn by our mistakes Restrooms and services Anything else, it is your meeting!? Parking Lot discussions that are off-topic

5 Purpose To learn how to write user stories, understanding: card, conversation, confirmation. Learn about the INVEST acronym and how to apply it in writing and evaluating user stories.

6 Approach to Learning Shuhari: a Japanese martial arts concept describing stages of learning to mastery. Shu - Follow (success = following technique) Ha - Break-Away (learn the limits of a technique) Ri - Fluency (shift techniques by moment, improvise)

7 What are User Stories? How would you describe user stories? What are ways projects (traditionally) communicate requirements? Why do you think user stories are so popular with Agile software development projects?

8 The Agile Manifesto Individual and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

9 User Stories Are... a written description (card) used for planning and as a reminder/promise note conversations to/which flesh out details provide confirmation criteria (to know work is completed)

10 They Are Not... Use Cases IEEE (or Detailed) Requirements Scenarios

11 Not Use Cases User stories are smaller than use cases because they are used to schedule work they cover a smaller scope tend to cover a single scenario of a use case (e.g. main success)

12 Not Use Cases Use cases live past the iteration, user stories survive up to the iteration they re scheduled in Use cases tend to include more details (e.g. user interface elements*) Use cases usually act to document agreements between dev and customers Use cases are a result of analysis activity, while stories initiate analysis conversations * despite admonishments to avoid this. (Cockburn 2001) This is a bad practice because instead of focusing on user goals we tend to focus on implementation when faced with a user interface preconception.

13 Use Case Example Compose and send an message. 1. User selects the New Message menu item. 2. System presents the user with the Compose New Message dialog. 3. User edits body, subject, and recipient(s). 4. User click the Send button. 4a. User provides no subject or recipient 4b. System cannot connect to mail server 5. System sends the message.

14 Not IEEE Requirements Eats, shoots, and leaves. Eats shoots and leaves. What am I? A cowboy in a saloon? A panda bear?

15 Not IEEE Requirements Entrée comes with choice of soup or salad and bread. Say again? Soup or (Salad and Bread) (Soup or Salad) and Bread

16 Detailed Req. Example 1. The product shall have a gasoline-powered engine. 2. The product shall have four wheels. a. The product shall have a rubber tire mounted to each wheel. 3. The product shall have a steering wheel. a. The product shall have a horn on the steering wheel. 4. The product shall have a steel body. Goal: To make it easy and fast for me to mow my lawn. (by the way, what do you think this is?)

17 Not IEEE: Verbalized Detailed requirements erroneously assumes that if everything is written down and agreed to then there can be no disagreements User stories do not document every last detail, but instead keep a few short sentences to jog our memory of needed conversations

18 Not IEEE: Comprehensible Detailed requirements often written in technical jargon unfamiliar to business users or customers User stories are written using words that everyone can understand enable people to recall unstated actions, because of their story nature* * In the late 70s, a study concluded people were found to be better able to remember events (including actions and inferred actions) if they were organized into stories. (Bower, Black and Tuner 1979)

19 Not IEEE: Right-sized Detailed requirements often sprinkled throughout a requirements document difficult to estimate and prioritize separately User stories self-contained with everything necessary to be estimated and planned easy to estimate and prioritize value

20 Not IEEE: Iterative Dev Detailed requirements not optimized for progressive detail completism: people feel compelled to fill a form when faced with one User stories encourage the deferring of details have a simple format, no set form

21 Not IEEE: Opportunistic Users don t know what they want exactly We always find things as the system develops Even if we could figure it all out ahead of time things change (eg market conditions, user needs) As human beings we can comprehend only a limited set of information Human beings make mistakes

22 Not IEEE: Opportunistic User stories thrive on opportunity do not rely on users knowing exactly everything fully in advance do not rely on you comprehending a vast array of details most importantly embrace change

23 Not Scenarios Scenarios are typically large and more encompassing than a use case too much scope too much detail Usually you can extract many upon many user stories out of a scenario

24 Example Scenario John and his family are thinking about taking a vacation. John doesn t like hotels, they re uncomfortable and would prefer to stay in a house. A house would provide at-home amenities and give each family member plenty of personal space. John wants to find a house near the beach and not too far from Disney World, Florida. He enters his search criteria Disney World Florida beach vacation, on the homepage. He further refines his search to homes that have 3 bedrooms, a pool and a DVD player. He reviews the remaining selections, checks maps of where they are, and availability. He finds one he likes and books it on-line through the web site.

25 Why User Stories? Emphasize verbal rather than written communication Generate tacit knowledge Comprehensible by everyone Right-sized for planning/estimating Work for iterative development Encourage participatory design

26 Writing a Story As a {user} I need/want to {fn} so that/to {biz value} Remember to use language that everyone can understand Focus on the user goal (3W s): Who is the user? What do they want to do? Why do they need to do that?

27 Example Stories A buyer can establish an account that remembers shipping and billing information. As a player I want to cast spells that heal friendly players I target. As a user I want to wirelessly use another PC s drive as a local drive on my PC.

28 Your Mission Today Write software for Rosie the Robot: As a state-of-the-art automated homemaker, Rosie needs your team to develop software that enables her to fulfill this role for the typical family of four with a dog. Individually create a backlog of 5-8 stories. Kids can contact Rosie to get a ride home from school.

29 Individual Negotiable Valuable Estimatable Small Testable INVEST

30 Individual As much as possible avoid dependencies between stories When dependencies arise Combine the stories into one larger (but independent story) Find a different way of splitting them up Alternatively put 2 estimates down (one for if the story is done first, or another done after)

31 Negotiable User stories are not contracts or requirements that the software must implement Provide the right amount of information a phrase or two that act as a conversation reminder notes about issues to be resolved Details that have been determined through conversation become tests.

32 Valuable Each story must be valued by the users and/or purchasers of the system/software Avoid stories only valued by developers Best way to make sure they re valuable is to have the customer write the stories User Proxies Be aware of biases when using user proxies

33 Valuable Sushi vs Sashimi View Controller Model

34 Estimatable Developers need to be able to take a guess at the size of a story (either in amount of time or effort) Reasons developers cannot estimate: Developers lack domain knowledge Developers lack technical knowledge The story is too big (referred to as epic )

35 Spike Story Rather than generate a feature (value), these stories generate knowledge/learning In XP a spike is a brief experiment (usually with throw-away code) to learn just enough to be able to make an estimate They are time-boxed learning stories, so we are able to put an estimate on them Because they are stories the Product Owner has visibility and can prioritize them

36 Small Story size matters Too big, they cannot fit into a sprint Too small, provide no value to the user Compound stories are epic stories that can be clearly decomposed into individual stories Complex stories that cannot be decomposed and are large because of uncertainty or high complexity -- then use a spike

37 Epic Story Stories that are too large to be accomplished in a single sprint are considered epic Epic stories can be used as placeholders in your backlog for far-future features When planning or working with a story ask, Is this the level of detail needed for where this story is in the backlog? As epics move up the backlog they decompose into smaller stories until they can be scheduled

38 Testable We need to be able to define what done means, through acceptance tests (high-level reminders, promote conversation) Focus on ways in which you need to test: Try with expired and bad credit card numbers. Common mistake teams make: Get overly detailed, Verify that... verify that... Write obvious tests like Check spelling.

39 Conversation & Confirmation Break-up into teams One person will play the role of the Product Owner, the rest are team members Organize your stories (consolidate and prioritize) You need to have 5-8 stories ready for the next planning meeting

40 Example Story Kids can contact Rosie to get a ride home from school. Are pick-ups from after-school activities okay? What about pick-ups off school grounds? est: med, 6 pts pri: high

41 Example Story Try various times (during & after school hrs, weekends). Try contacting by phone. Try contacting by or sms msg. Try with an emergency over-ride code. Try a pick-up off school grounds. (fail)

42 Are you INVESTed? As a team review your stories. Are they INVESTed? Rewrite them if necessary. Trade them to another team, and let them evaluate them.

43 Catalog of Story Smells Stories are Too Small Interdependent Stories Goldplating Too Many Details Including User Interface Detail Too Soon Splitting Too Many Stories Customer Has Trouble Prioritizing Customer Won t Write and Prioritize Stories Thinking Too Far Ahead

44 Organic Example

45 Web-based Tools Mingle (by Thoughtworks Studios) RallyDev (by Rally Software) VersionOne (by Version One) Scrumworks (by Danube Technologies)

46 Other Topics How to handle non-functional requirements? Paper or Software? User Stories and the User Interface Retaining Stories Bug Stories

47 Review What did you learn in the past couple of hours? Did we cover your burning question? Retrospect on the Meeting: (+/-) What can I learn as a presenter? Topics I can cover more fully? Other Agile workshops you might want?

48 Thank You You can find a copy of this workshop at: Useful books: User Stories Applied: For Agile Software Development, by Mike Cohn URLs: