Download as PDF, PPTX
Uploaded byFabio Armani
User Stories Writing - Codemotion 2013
The document outlines the process of writing user stories within an agile development framework, emphasizing the importance of a clear, concise, and user-focused approach. Key aspects include the structure of user stories, characteristics that make them effective (independent, negotiable, valuable, estimable, sized appropriately, and testable), and methodologies for gathering user information. It also discusses the concept of epics and themes as higher-level collections of user stories, along with practical tips for story writing and management.
More Related Content
Similar to User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013
- 1. Stefano Leli, FabioArmani User Story Writing f.armani@open-ware.org - stefano.leli@gmail.com
- 2. What were theythinking? Team Product owner
- 3. What were theythinking? • Chose a product owner for each team • 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
- 8.
- 9.
- 11. User Story Writing Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org What is a "User Story”
- 12. User Story: is • A User Story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. • A User Story is a proposed solution from a user’s perspective. • User Stories have Acceptance Criteria (or Conditions of Satisfaction) and Validations.
- 13. User Story • Theuser story also serves as a metaphor for our entire, incremental-value-delivery approach, i.e.: – define a valuable user value story – implement and test it in a short iteration – demonstrate/and or deliver it to the user – capture feedback – validate it from a business perspective – learn – repeat forever!
- 14. User Story • Theuser story can describe: – Features – Non-Functional Requirements – Bug Fixes • It is the primary development artifact in XP/ Agile development methodology • High level requirements document • Focuses on Who, What and Why of a feature and not How
- 15. What a "UserStory" is not
- 16. User Story: isnot • It is not a use case or a software requirement, i.e. a formal and long specification document • One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications
- 19. User Role: modeling • User Roles – Various types of users • Role Modeling – Brain storming – Organizing – Consolidating – Refining • Personas – Imaginary representation of an User Role – Could use pictures too • Extreme Characters
- 20. User Tester UX Dev BA PO SM
- 21. User Stories: gathering • User Interviews – Select right interviewees – Ask open-ended, context-free questions • Questionaries – Best if there is a large user population – When you need answers to specific questions • Observation – Best for In-House developments • Story writing Workshops – Effective during the initial phase of the project / release
- 22. Coin Sorting How longwill it take to sort this bag of coins?
- 24. 3C Card, conversation &confirmation
- 27. user stories needto be short and concise enough so that they can fit on a single card
- 30. the conversation ismuch much more important than the story itself
- 33. by definition, userstories must be testable
- 34. A User Storyshould cut throughout all the layers of the architecture
- 35. Initial User Stories(informal)
- 36. Example User Stories Studentscan purchase monthly parking passes online. Parking passes can be paid via credit cards. Parking passes can be paid via PayPal ™. Professors can input student marks. Students can obtain their current seminar schedule. Students can order official transcripts. Students can only enroll in seminars for which they have prerequisites. Transcripts will be available online via a standard browser.
- 37. #52 Students can purchase monthly parking passes online Priority: 8 Estimate: 4
- 38. Initial User Stories(formal)
- 39. # User Story Title As a <user role> I want to <goal> so that I can achieve some <benefit>.
- 40. #52 Purchase MonthlyParking Pass As a student I want to purchase an online monthly parking pass so that I can drive to school.
- 41. #52 Purchase MonthlyParking Pass As a student I want to purchase an online monthly parking pass so that I can drive to school. Priority: Must Estimate: 5
- 42. #97 Find Reviews Near Address As a typical user I want to see unbiased reviews of a restaurant near an address so that I can decide where to go for dinner. Priority: Must Estimate: 8
- 43. #97 Find Reviews Near Address As a typical user I want to see unbiased reviews of a restaurant near an address so that I can decide where to go for dinner. Priority: Should Estimate: 5
- 45. what makes agood story Bill Wakefield is credited with this acronym
- 46. INVEST in UserStories • Independent – Avoid dependencies with other stories – Write stories to establish foundation – Combine stories if possible to deliver in a single iteration • Negotiable – Stories are not a contract – Too much detail up front gives the impression that more discussion on the story is not necessary – Not every story must be negotiable, constraints may exist that prevent it • Valuable – Each story should show value to the Users, Customers, and Stakeholders
- 47. INVEST in UserStories • Estimable – Enough detail should be listed to allow the team to estimate – The team will encounter problems estimating if the story is too big, if insufficient information is provided, or if there is a lack of domain knowledge • Sized Appropriately – Each story should be small enough to be completed in a single iteration – Stories that may be worked on in the near future should be smaller and more detailed – Larger stories are acceptable if planned further out (Epics) • Testable – Acceptance criteria should be stated in customer terms – Tests should be automated whenever possible – All team members should demand clear acceptance criteria
- 48.
- 49.
- 51.
- 53. Acceptance Criteria • Acceptancecriteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
- 54. Acceptance Criteria • ACrepresent high-level criteria from the perspective of the user or stakeholder. • It’s important to consider Positive and Negative criteria. • The PO should collaborate with testers to create good Acceptance Criteria (Conditions of Satisfactions).
- 55. #73 Upload Files AS A wiki user I WANT to upload a file to the wiki SO THAT I can share it with my colleagues
- 56. Conditions of Satisfactions Verifywith .txt and .doc files Verify with .jpg, .gif and .png files Verify with .mp4 files <= 1 GB Verify no DRM-restricted files
- 57. #85 View Attachmentsin Messages AS A user viewing messages that contain more than simple text I WANT to be able to open them and see the contents SO THAT I can view the additional information and understand the message fully
- 58. Acceptance Criteria Asa conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork. Acceptance Criteria: 1. A user cannot submit a form without completing all the mandatory fields 2. Information from the form is stored in the registrations database 3. Protection against spam is working 4. Payment can be made via credit card 5. An acknowledgment email is sent to the user after submitting the form.
- 59. Acceptance Criteria As a conference organizer, I want to send a ticket via email at the end of the online registration so that I can speed up the check-in process. Acceptance Criteria: 1. The attendee must be inform that he will receive an email with an electronic ticket 2. The email has been sent correctly 3. The electronic ticket must have a QR code 4. The QR code must be readable by a smartphone camera
- 60. Give-When-Then • Given-When-Then isa useful format for expressing testable acceptance criteria • Created by Dan North Given <context> When <action> Then <expected result>
- 61. Feature A usercan view attachments, links, images and stories contained within messages
- 62. #39 View Attachmentsin Messages AS A user viewing messages that contain more than simple text I WANT to be able to open them and see the contents SO THAT I can view the additional information and understand the message fully
- 63. Acceptance Criteria As auser I want to open the attachments contained in an email so that I can view the additional information and fully understand the message. Acceptance Criteria: 1. The user opens a message that contains a file attachment or story 2. The user opens a message that contains a link 3. The user opens a message that contains an image
- 64. Acceptance Criteria View Attachments in Messages Acceptance Criteria: Scenario: The user opens a message that contains a file attachment or story GIVEN the message contains a file attachment or story WHEN I click the message link to open the message THEN the message opens and shows the attached file or story
- 65. Acceptance Criteria View Attachments in Messages Acceptance Criteria: Scenario: The user opens a message that contains a link GIVEN the message contains a link WHEN I click the message link to open the message THEN the message opens and shows the link as an active hyperlink
- 66. Acceptance Criteria View Attachments in Messages Acceptance Criteria: Scenario: The user opens a message that contains a file attachment or story GIVEN the message contains a file attachment or story WHEN I click the message link to open the message THEN the message opens and shows the attached file or story
- 67. Acceptance Criteria View Attachments in Messages Acceptance Criteria: Scenario: The user opens a message that contains an image GIVEN the message contains an image attachment WHEN I click the message link to open the message AND hover my mouse of the image file posted in the message THEN the image can be viewed as a thumbnail
- 68. Pros & Cons ü Short and Easy to modify as in when requirements changes ü Allow projects to be broken into small increments ü Easier to estimate the development effort ü Completed User stories can go for development ü It drives the creation of Acceptance tests û Initial learning curve û They require close customer contact û Rely more on competent developers
- 69. User Stories Applied • Mike Cohn
- 70. User Story Writing Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org stefano.leli@gmail.com f.armani@open-ware.org @sleli @fabioarmani
- 73. Epics • Epics arelarge user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.
- 74. Preference Training Epic Asa typical user I want to train the system on what types of product and service reviews I prefer so it will know what characteristics to use when filtering reviews on my behalf
- 79. Themes • A themeis a collection of related user stories. • For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. • Themes are often used to organize stories into releases or to organize them so that various sub- teams can work on them.
- 80. Keywords Training Theme Asa typical user I want to train the system on what keywords to use when filtering reviews so I can filter by words that are important to me
- 81. From Features toTasks Epic Feature Story
- 82. Managing Epics • Epicsare too large to estimate and can be split into multiple stories • Epics represents – Complex functionality – Placeholders for low priority stories • Types of Epics – Compound Stories – Complex Stories • Different ways to split Epics – Various small actions in the Epic – Along the boundaries of Data – Depending on complexity
- 83. Managing Tiny Stories • Tiny stories are too short • Its better to – Combine multiple tiny stories – Group them into Themes
- 84. Creating User Stories • Sequentially numbered • Customer Focused – Written from a User's perspective – Better if written by the user – Avoid technical jargons • Shouldn't be too short nor too long • Should be complete and testable • Should be able to implement by two people in a single iteration • Avoid infrastructure, technology or service elements
- 86. 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?”)
- 87. Story Writing Story writingwith your customer: • Low fidelity prototypes to get the main flows • Get breadth first • Use user roles / personas to help identify missing stories • Compare against competing products
- 88. Decomposing Stories • CompoundStories – 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
- 89.
- 90. Splitting Stories • Patternsfor 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
- 91.
- 93.
- 94. Technical Stories • AddingCI, optimizing 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 minimize 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 ...
- 95. Story: smells • Too small or too big • Estimates don’t converge • No scenarios / acceptance criteria • Interdependent • Gold-plating
- 96. Story: more smells • Too detailed • UI defined • Thinking too far ahead • Splitting too frequently • Trouble prioritising • Technical language
- 97. Pros & Cons ü Short and Easy to modify as in when requirements changes ü Allow projects to be broken into small increments ü Easier to estimate the development effort ü Completed User stories can go for development ü It drives the creation of Acceptance tests û Initial learning curve û They require close customer contact û Rely more on competent developers
- 98. User Stories Applied • Mike Cohn
- 99. User Story Writing Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org stefano.leli@gmail.com f.armani@open-ware.org @sleli @fabioarmani