Writing Effective User Stories
•Als KEY, PDF herunterladen•
44 gefällt mir•6,696 views
Intended as a presentation for scrum product owners and analysts. A crash course in writing good user stories
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Writing Effective User Stories
Ähnlich wie Writing Effective User Stories (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Writing Effective User Stories
- 1. Writing Effective User stories Presented by Carlo Kruger December 2009
- 2. What were they thinking? •Split into teams, with one product owner •Product owners may only communicate with the team through imperatives (“it must have/do...”) or similes (“it’s like...”) •Cannot use the name of the thing in a sentence (“it must pour tea” for a teapot is not allowed) •Teams cannot ask questions •Teams have 2 minutes to draw the object seen by the PO
- 3. Moka Pot
- 6. Communication problem The system must store an address and business phone or mobile phone 1 Address + (business phone or mobile phone) (Address + business phone) or mobile phone 2
- 7. Dude, where’s my car? •Product shall •Have a gas engine •Four wheels •Rubber tire on each wheel •Has a steering wheel •Has a steel body
- 8. Focus on intention •As a user I want to mow my lawn quickly and easily •As a user I want to be comfortable while mowing my lawn
- 9. So now what? We make decisions based ...but we do it often on the info we have This is where user stories come Rather than make one in ...we spread decision- set of all-encompassing making across the decisions project
- 10. The Product Backlog iceberg { 1-2 sprints worth of stories Stories ould sh ed Features ll y a ress ea ll Id xp ies! e e or ti ll b r s t s a su se Epics / Themes
- 11. What are epics? •Large fuzzy requirements •Lower priority •May consist of a number of features
- 12. What’s a feature? •A set of requirements which can be grouped •which deliver value to a group of users
- 13. What are user stories? As a: <user role or persona> I want to: <do something, a piece of functionality> So that: <achieve some business value or statement of intent>
- 14. The 3 C’s •Stories are traditionally written on note cards Card •Cards may be annotated with estimates, tests, etc •Details of story come out Conversation during conversations with product owner •Acceptance tests confirm Confirmation the story was coded correctly
- 15. But what about the details? •As a user I want to be able to cancel a reservation so that I can get a refund for the trip not taken • Does the user get a full or partial refund? • Is the refund to the credit card or is it a site refund? • How far ahead must the reservation be cancelled? • Is it the same for all hotels? • How about all site visitors? Can frequent travellers cancel later? • Is a confirmation provided to the user? • How do provide this confirmation?
- 16. Acceptance tests Given: it is 2 weeks till my flight and I paid $1000 for the flight and I am not a frequent traveler When: I cancel my flight Then: I get a 50% refund ($500) and my flight is cancelled •Describes starting state, event and final state •Use ‘real’ examples with meaningful values
- 17. The Happy Path •Every story should define the default scenario •similar to happy path in a use case •extend with negative scenarios and edge cases
- 18. Coin Sorting (an exercise) How long will it take to sort this bag of coins?
- 19. Talking to users •Ask open ended questions •closed = “Yes or No” •open = “What would you be willing to trade for performance?” •Give user options (“This one or that one?”)
- 20. Story writing with your customers •Low fidelity prototypes to get the main flows •Get breadth first •Use user roles / personas to help identify missing stories •Compare against competing products
- 21. User Roles •allow users to vary by •what they use the software for •how they use the software •background •familiarity with software / computers
- 22. Role modelling • Every product has more than one type of user • administrators • clerks • managers • when we write with only one perspective • we assume all users have the same goal • leads to missing stories
- 23. An extreme user modelling story
- 24. What makes a good story? Independent Negotiable INVEST Valuable Estimable Small Testable
- 25. INVEST •Independent • Dependencies lead to prioritisation problems •Negotiable • Stories are not contracts • leave the team room to manoeuvre •Valuable • to users or customers (rarely if ever developers) • try to rewrite developer stories to reflect value to the customer
- 26. INVEST •Estimable • we plan using user stories so we must be able to estimate them •Small (sized appropriately) • Compound stories are multiple stories • Complex stories are intrinsically large •Testable • if you can’t test it, how do you know when you’re done?
- 27. What makes a good user story? •It describes what a user does •Explicitly states dependencies •Takes a slice through the system •Ends with a meaningful goal • instead of “a home seeker can maintain her search criteria” • a home seeker can create her search criteria • a home seeker can review the results of a search • a home seeker can change the geographic area of a search
- 28. Non-functional requirements “...is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours” - Wikipedia • Security • Usability • Testability • Maintainability • Extensibility • Scalability • Portability • Performance
- 29. Formulate NFR’s as a story Acceptance Criteria Performance Constraint •10,000 concurrent R/W transactions take place The system must answer any request in less than 1 second •Each transaction is 500Kb •System config is ‘small enterprise’
- 30. Linking to functional requirements Theme Functional requirement Performance Security Robustness As an enterprise user, I want to select a Emailing recipient from my contact list, so that I can X X get the correct address
- 31. Technical Stories • Adding CI, optimising DB, upgrade to latest Oracle, etc. • Consider trying to write a user story so that you are forced to define the business value • No user facing functionality, e.g. Rating engine consumes some output • Consider writing as a user story with the engine as the user • e.g: As the rating engine, I want well formed CDR’s so that I can minimise error logging • Don’t hurt yourself trying to force it; sometimes it’s OK not to use the format • Be careful that these aren’t tasks that have been elevated to stories...
- 32. Decomposing user stories • Compound Stories • a number of smaller stories / scenarios • split into meaningful chunks • Complex Stories • if it’s largely unknown, consider a spike • try find ‘natural’ seams in the story • Combining stories • stories should be about 2 days work • if too small combine e.g. bugs into one story
- 33. Patterns for splitting stories • Workflow steps • Business rule variations • Major / Minor effort • Simple / Complex • Variations in available data • Data entry methods • Defer performance • Operations (e.g. create / update / delete) • Spike
- 34. When do I write stories? •5-10% of total team effort should be spent on preparing for the next sprint •i.e. about 50% of analyst’s time in sprint •still need to be available to team (should be answering 80% of queries in <10min) •estimation meetings in off-week
- 35. Story writing workshops •Include team, users, customers •Brainstorm to generate ideas •Write as many as possible •Start with epics and iterate •or use mindmaps •Prioritise later
- 36. Story Workshop ets is over paid tick rrest eds its I f th R50 e tot 00, t al un wa rrant hen a If a warran rt ued. of a Cops & Fines t of e cou E ach p own re olice sta port of o tion ne verdue tickets be is s en th rrest m ust issue d, th st is the a The viola arr e ed of be set tion mus t be i nform e can master l ist of ve t be link e d to a mus ria l dat Our officers now carry GPS units, so the hicles. W so th at a t co-ordinates of the offence must be the vehi cle manu e also n type (se facturer ee d logged on the ticket. The officer will dan, SUV , colo ur, It wo reg istrat , etc) an login to the mobile app using their ion d uld b phot e so badge number and password ogra cool of th ph o if the e vio r vid show latio eo cl n on n cou ip a Go ld be ogle We would like to ‘name and Map shame’ top offenders on our officer FaceBook page automatically, nnual bo nus of an The a ber of on the 1st of each month is linke d to the nu m s that h ave been violation n d pai d Credit & thanks to Aslam Khan for the stories issue d a
- 37. Story smells •Too small or too big •Estimates don’t converge •No scenarios / acceptance criteria •Interdependent •Gold-plating
- 38. More smells •Too detailed •UI defined •Thinking too far ahead •Splitting too frequently •Trouble prioritising •Technical language
- 39. Use cases vs. user stories •Size •User stories much smaller than use cases •Completeness •use cases are exhaustive, user stories much less detail •Longevity •use cases intended as permanent record, user stories rarely last beyond the sprint
- 40. References •Mike Cohn - ‘User Stories Applied’ •Leffingwell & Behrens - ‘A User Story Primer’ •Victoria Hall - ‘Crafting Better Scrum Requirements’ •Mike Cohn - ‘An introduction to user stories’ •Roman Pinchler - ‘Agile Product Management with Scrum’
Hinweis der Redaktion
- The aim of this workshop is to get people aware of the complexity of software development.
- This is a relatively simple object that most people will have come across in day-to-day life. It has a single well understood purpose.
- This is a more complex object
- This is a one-of-a-kind object. Much of what we&#x2019;re building in software development is unique. The language that we use to describe this thing is therefore inexact and open to interpretation.
- The aim of this is to illustrate how much better vocal communication is over documentation. Have the participants vote as to which it is, and then pick one to emphasize when you say the sentence.
- This next 2 slides illustrate the importance of communicating the intention of the user and not just the solution description. Remember that most people rarely read the whole requirements doc
- So this is where user stories come in
- It&#x2019;s important to note that in total, you should only have 35-50 items in your backlog at any one time. There should be a steady flow of epics to features to stories
- By the time it comes to implement epics, we might have changed out minds based on what we&#x2019;ve already built. Therefore don&#x2019;t invest the time to define them more clearly until you&#x2019;re ready to build them
- The mantra here is &#x2018;Just Enough, Just In Time&#x2019;
- This format was the product of Mike Cohn&#x2019;s work.
- Ron Jeffries and his work in Xtreme Programming is credited with the idea behind this formulation.
- We use acceptance tests to help us understand how the story should be implemented. They supply the details that the team needs.
- This exercise is meant to illustrate the importance of asking questions of the customer / user. The trick is when the team has sorted the bag of mixed coins by denominations you tell them you actually wanted it by date.
- Stresses the importance of not closing off avenues to explore with the users.
- Techniques for helping you talk to your customers.
- The story here is that in pitching a product at an extreme users (the elderly) OXO actually ended up with a better overall design of a potato peeler that appealed to everyone. Your extreme users can help you find ways in which people use your products that might not have occurred to you.
- Bill Wakefield is credited with this acronym for the test of what constitutes a good user story. Think of this as a checklist when you are story writing.
- The important part here is to make sure that your acceptance criteria are defined. Note: you may have multiple constraints for a particular type (e.g. batch vs real-time performance)
- This idea is stolen from Roman Pinchler&#x2019;s book.
- Remember to at least try writing it as a user story first...