![User Stories | Convention
• Rachel Davies is credited with inventing:
As a [type of user]
I want [some particular feature]
so that [some benefit is received]
• Example:
As a bank customer
I want to view my current account balance
so that I know my recent deposit went through.
• Sometimes features that describe technology updates or UI changes don’t really
work with the model.
14](https://image.slidesharecdn.com/thomashaver-examplemapping-230616213517-5a1394f8/75/Thomas-Haver-Example-Mapping-pdf-14-2048.jpg)
![User Stories | Convention
• Rachel Davies is credited with inventing:
As a [type of user]
I want [some particular feature]
so that [some benefit is received]
• Example:
As a bank customer
I want to view my current account balance
so that I know my recent deposit went through.
• Sometimes features that describe technology updates or UI changes don’t really
work with the model.
14](https://crownmelresort.com/image.slidesharecdn.com/thomashaver-examplemapping-230616213517-5a1394f8/75/Thomas-Haver-Example-Mapping-pdf-14-2048.jpg)
Uploaded byQA or the Highway
Thomas Haver - Example Mapping.pdf
The document describes an example mapping group activity to help clarify acceptance criteria and examples for a user story. The group is provided a sample user story about adding and editing contact details in an Amazon mobile app. Participants will generate rules and examples for the story, which will be reviewed by the group. Example mapping is presented as a way to facilitate collaboration and ensure a shared understanding of user stories before development begins.
More Related Content
Similar to Thomas Haver - Example Mapping.pdf
Thomas Haver - Example Mapping.pdf
- 1. Example Mapping The NewThree Amigos
- 2.
- 3. • There willgroup activities • Participation in our activities is voluntary • Questions are welcome at any time 3 Ground Rules for Today
- 4. Rules and Examples witha Blockbuster Movie
- 5. Group Activity |Blockbuster Movie • Form teams with the people sitting closest to you. • Write three RULES for a blockbuster • Don’t share your rules with other attendees • Sample rule: “Comic Book character is featured” 5 Adapted from Matt Wynne, “Stories, Rules, and Examples.” (BDDx, 2014) As a big-time Hollywood movie executive I want to create the next blockbuster movie In order to make a lot of money
- 6. Group Activity |Blockbuster Movie • Create three EXAMPLES that illustrate your rules 6 The movie is released on the July 4th weekend Will Smith starring alongside Aliens
- 7. Group Activity |Blockbuster Movie • Share your EXAMPLES with another team. • Attempt to guess the other team’s rules. • Your team may create new EXAMPLES and ask the other team to confirm the examples meet the RULES. • How many examples did it take to guess the rules correctly? 7
- 8. Group Activity |Blockbuster Movie 8 The movie is released on the July 4th weekend Robert Downey Jr is the lead actor Must release on a Holiday Must feature an established Hollywood Star Deadpool kills Ryan Reynolds before he can star in the Green Lantern The movie breaks the fourth wall
- 9. Group Activity |Blockbuster Movie Why do we need both RULES and EXAMPLES? 9
- 10. Use the EXAMPLESto illustrate the RULES of USER STORIES 10 Examples Rules / Acceptance Criteria User Stories
- 11. Examples Examples • Examples cantake various forms: input-output data pairs, sketches of the user interface, bulleted lists of different steps of a user workflow or even an Excel workbook illustrating a calculation or a report. • All examples describe a behavior as a combination of context, action, and outcome. • Some examples are formulated into scenarios when a user story is ready. BDD tools turn these scenarios into executable tests before the related behavior has been implemented in the application itself. 11
- 12.
- 13.
- 14. User Stories |Convention • Rachel Davies is credited with inventing: As a [type of user] I want [some particular feature] so that [some benefit is received] • Example: As a bank customer I want to view my current account balance so that I know my recent deposit went through. • Sometimes features that describe technology updates or UI changes don’t really work with the model. 14
- 15. Behavior Driven Development 15 JohnFerguson Smart, “Serenity BDD”, https://www.thucydides.info, accessed 2018-04-25. http://bddbooks.com/ BDD promotes requirements by example, collaboration, lower cost in resolving defects, and automation in the form of business value.
- 16.
- 17. Encourages Collaboration BDD requirespeople to work together to create the requirements / tests. All roles balance each other. 17
- 18. Living Documentation Living Documentationis a form of documentation that represents the current state of the application, which is updated in real-time. • Scenarios make up the living documentation, which should be understandable by everyone. • Scenarios should be written in domain-specific terms to describe the behavior of the application. 18
- 19.
- 20.
- 21. From a UserStory to Specifications • Before development starts, have a conversation to Clarify and Confirm • The Three C’s • Card • Conversation • Confirmation 21 https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
- 22. Card • User storiesare written on cards. • The card does not contain all the information in the requirement. • The card has just enough content to identify the requirement. • The card is a token that represents the requirement. 22
- 23. Conversation • The conversationis an exchange of ideas and opinions. • This conversation takes place over time: during estimation and planning before implementation. • The conversation is verbal and often supported by documentation. The best supplements are examples – specifically executable examples. 23
- 24. Confirmation • An acceptancetest. • For complex stories, confirmation using examples (and automation) is preferred. • The confirmation provided by the executable specification steers the approach of card and conversation. 24
- 25. Structured Conversation Structured Conversationis a facilitated exchange of ideas that conform to a predefined form. • A structured conversation is: • Collaborative - all attendees participate actively • Diverse Perspectives - all primary areas of a team are represented • Short – regular workshops in a time- box so the feedback loop is quick • Progressive Focus – capture the progress of the workshop in real-time • Consensus – agreed concrete examples measure the workshop’s success 25
- 26. The Example Mapby Matt Wynne 26 Question Rule https://speakerdeck.com/mattwynne/rules-vs-examples-bddx-london-2014 https://cucumber.io/blog/2015/12/08/example-mapping-introduction
- 27. Process 27 • The singleUSER STORY is written on YELLOW card and placed at the top of the map. • The acceptance criteria as a RULE is written on a BLUE card placed below the User Story. • Create one or more EXAMPLES written on GREEN cards placed below each rule. • Any QUESTION that no one in the workshop can answer is written on a RED card. • Continue the session until a Time-box is met or everyone believes the story is elaborated sufficiently.
- 28. Feedback Understanding of theUser Story Question Rule Example "The one where..." Development work is not ready to begin User Story might be too large Rule might be too dense Question Question Rule Rule Example "The one where..." Example "The one where..."
- 29. Benefits 29 Creates a shared understanding Examplesbecome user scenarios Rules become acceptance criteria Reduces rework of large or unclear stories
- 30. An Example ExampleMap 30 Present at a Virtual Conference Speaker must have a machine capable of AV Presentation must be stored in an accessible location Conference must have means to record presentation Lenovo ThinkPad has a built-in speaker / microphone GoTo Meeting is valid How do you address hands- on activities virtually? Will the session be live for attendees? Slideshare is valid Youtube is valid Will the session be edited afterward? Confide is not valid MacBook Pro has a built-in speaker / microphone Will the recorded presentation only be available to paid attendees?
- 31. A Word ofAdvice Good Examples should be BRIEF: • Business Language – enables collaboration and feedback • Real Data – helps to discover white spots in requirements • Intention revealing – way to describe the tests by focusing on what we wanted to achieve and not how • Essential – include only relevant details in the scenario • Focused – the scenarios should illustrate a single rule only 31
- 32. Other Common RefinementActivities • Three Amigos • Specification Workshop • Discovery Workshop Whichever method is used, these activities must be done regularly! 32 Workshop Background Materials: http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/ https://gojko.net/2008/11/12/specification-workshops-an-agile-way-to-get-better-requirements/ https://dannorth.net/2010/08/30/introducing-deliberate-discovery/
- 33.
- 34. Example Mapping GroupActivity 34 Group Activity (15- minute time-box) As a group, we’ll conduct an example mapping session with an active User Story We’ll review as a group
- 35. User Story Candidate •Amazon Mobile App • This is not intended to be an ideal story. 35 As a user I want to add and edit my contact details so I can keep it up to date
- 36.
- 38.
- 39.
- 40.
- 41.
- 42. Metrics | PercentBusiness Rule Percent business rule is the percent of business rules covered with specifications (test cases) for regression, project release, or deploy/patch validation (smoke tests). SPE # of business rules with specifications PBR (%) = -------- = --------------------------------------------------------- BR # of total business rules PBR = Percent Business Rule SPE = # of business rules with specifications BR = # of total business rules 42
- 43. Metrics | EffectiveAutomation Effective automation is the percent of automation for an application’s regression, project release, or deploy/patch validation (smoke tests) that can be automated from the total number of applicable automation candidates. ATC # of test cases automated EA (%) = -------- = --------------------------------------------- TC # of total candidate test cases EA = Percent Automation ATC = # of test cases automated TC = # of total candidate test cases 43