The Key to Agile Analysis Starts with Understanding: Using Given-When-Then to Write Great User Stories

Presented as a 1-day workshop in conjunction with BAWorld Dallas, February 2015.

Synopsis:
User Stories seem like an easy idea. You write down a statement, “As a …, I want …, So ….” Then the team starts developing—except the reality is rarely that simple. In the end, Product Owners and Agile Business Analysts are left with numerous questions as they work to support their teams:
• Are User Stories really a placeholder for a conversation? And if so, how does that work?
• I thought agile didn't need any documentation. What does it mean to write a story and how much should be written?
• What about defects and technical stories, are they stories too?
• What is the difference between requirements and acceptance criteria?
• Why should I use "Given-When-Then?"
• Who should be involved in writing and reviewing requirements?

Whether you write on index cards, post-it notes™, or a software tool like Rally and Jira, User Stories have common elements. This session will answer these questions with practical examples of what's included in a good user story and how they should be used to bring stakeholders and the development team to a common understanding.

Supporting:
• IIBA BABOK, Chapter 9.30 - User Stories
• Agile Extension to the BABOK, Section 4.6.1 - The Delivery Framework, Get Real Using Examples

Learning Objectives:
1. Describe the elements of a good user story
2. Produce requirements written in clear and understandable language
3. Demonstrate functionality meets your requirements with small scenarios

Transcript

1. The Key to Agile Analysis Starts with Understanding Using Given-When-Then to Write Great User Stories
2. @JeffreyGoodReq goodrequirements.com www.linkedin.com/in/jeffreydavidson
3. A bit about you •  Name •  What do you know about user stories? •  Something fun or unique
4. TRADITIONALLY . . .
6. A Team Member Wondered…. •  How can I eliminate the frustration we experience with requirements today? •  What do we need to do to decrease all the swirl related to changing requirements? •  Is it really necessary to process all of these change requests?
7. She Felt it Always Seemed…. Many conversations were had. Lots of documentation was produced.
8. But In The End…. And no matter what, by the end of the project, everyone was worn out and frustrated. Everyone crossed their fingers, hoping it was all correct and that stakeholders really read it.
9. And When it All Went Wrong… That’s not what the requirement said. - Tester It wasn’t in the requirements. - Developer It was in that e-mail I sent you 3 months ago. - Stakeholder I told you that would be a change request. - Project Manager Blame is often placed on the person primarily responsible for the documentation because the problem was with the requirements.
10. So What’s The Problem? •  What do you think the root cause of the frustration is?
12. What Is The Problem? •  We often assume it’s possible to identify all the requirements accurately up front •  Falsely believe that the work to produce requirements “auto-magically” happens §  Not enough time §  Not the right people §  Disjoined conversations •  Fail to plan and account for the changes that will inevitably occur
13. How Bad Is It? What percentage of overall project time is spent gathering, elaborating, and communicating product requirements? What percentage of requirements, as originally defined, change during the course of the project? What percentage of features, as ultimately delivered, are rarely or never used by the product’s end-users? ?? ?? ??
14. Traditional Requirements •  According to the Standish Group, they are the #1 reason for project failure. •  Traditional planning assumes: §  The customer can describe exactly what they want §  The customer knows exactly what they want §  The customer can give you a complete list of every feature needed for the project §  The customer can provide this level of detail without ever having seen the end product
15. Requirements Myth •  If you write them down, users will get exactly what they want. •  At best, users will get exactly what was written down, which may or may not be anything like what they really want.
16. Requirements Reality •  Users have difficulty describing what they need – the usual response is IKIWIS “I’ll know it when I see it” •  Without an empirical process, the customer has no way of reconciling the picture in their heads with reality until they actually experience the product for the first time: in final test or UAT •  Every requirement is a #1 priority.
17. Embrace Emergent Requirements •  Customers will never know all of the requirements upfront •  Emergent requirements are the rule, not the exception •  Help customers VISUALIZE the end result by modeling and testing early •  Early focus is getting the breadth of features instead of the depth of each one •  Keep a “Just Enough” attitude
18. ALL ABOUT USER STORIES
19. What is a User Story? •  Card •  Conversation •  Confirmation
20. Where do User Stories come from? •  Product Owner •  Team Member •  Analyst •  Anyone
21. Lifecycle of a Story Sprint Team w/ PO input Story is planned for a Release Story is Estimated Team Story is Written Anyone on team High-level acceptance criteria defined PO, BAs Story is Prioritized in backlog PO w/ Team input Story is targeted for a Sprint Team w/ PO input Story is Reviewed Team Story tasks are defined Team Story tasks are completed Team Story is Accepted Product Owner Story is Groomed Team & PO Story is demonstrated Team
22. Timeline Overview Sprint  1   Mon Tues Wed Thur Fri Sprint Planning Daily Scrum! Story Review! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Daily Scrum! Retrospective! Demo! Sprint Review! Story Review! Retrospective! Sprint Review! Release Plan! Demo! Sprint  2   Sprint Planning
23. Focus for Refinement Current   Sprint   +1   +2   +3   +5   +4   3   4   5   6   7   8   Focus  for   Story  Review   Focus  for   Refinement   Workshop   Focus  for  Product   Owner  
24. What’s included? •  User story •  Acceptance criteria •  Business rules •  Mock-ups •  Notes •  Description •  Status •  and so on …
25. What’s a good one? Independent Negotiable Valuable Estimable Sized appropriately Testable •  Bill  Wake  
26. What kinds are there? •  Functional •  Non-functional •  Technical •  Spikes •  Tracking •  Defects •  Epics
27.                                                   Prioritized Backlog 0 - 3 Months * URGENT RELEASE SCHEDULE 4 - 6 Months * FUTURE NEAR TERM BUCKET 7+ Months * FUTURE DISTANT BUCKET LOW Prioritization HIGH ✴  Release schedule timeframes
 are examples only
28. What do you need to know about your product? image: discovertodeliver.com
29. User Roles •  Define who your users are T I P : NEVER “User”
30. Sample Persona Name: Kylie Role: Loan Officer (POS User, P&P User, Product User) Location: Melbourne, Australia Age: 26 Technical Level: Very Tech Savvy Motivators Looking to resell her loans at the highest price quickly. Best product selection, whole process perspective, builds her reputation on Service. Site Usage Check for the best pricing (for both her and the customer), check for proper product fit for her customer, check loan status. Default Home Page Daily Rate Sheet Product Information Product Selection (recommendation and direct / exception handling) Locking Alerts: Price Changes, New Product Announcements (Hot Products or Bulletins) Tools Daily Rate Sheet Product Selection (recommendation/best fit, comparison, direct select) Pricing Product Information Forms Reporting (reports TBD) “My favorite investor is a one stop shop – they offer all the services I need to fill my customers needs.” “Their website allows me get a fast price indication and product selection” On days when rates are likely to fluctuate, Kylie shows up an hour early to get prepared. When the new rates are available she knows she will be in touch with dozens of customers during the day. She’ll likely lock in rates on 10 or so loans as apposed to the 1 or 2 on normal days. Day In the Life
31. Story Slicing
32. Prioritizing •  MoSCoW
33. Prioritizing •  Kano image: mindtheproduct.com
34. Prioritizing •  Weighted Shortest Job First
35. UNDERSTANDING COMES FROM TELLING STORIES
38. Pick a role §  Princess §  Fireman §  Singer §  Scientist
39. Pick a sidekick §  Cousin §  Magic pet monkey §  Stuffed animal §  Talking bird
40. Pick an activity §  Walking §  Flying §  Having a picnic §  Shopping
41. Pick a place §  In the forest §  By the ocean §  On the roof §  In town
42. Pick 2 events §  You hear a loud roar §  Your sidekick chases a bird §  A furry monster walks up §  A horse asks for your help §  You shrink to 4” high
43. Pick a response §  Say “Not again!” §  Pull a biscuit out of your pocket §  Laugh §  Fall into a puddle §  _____________________
44. Once upon a time _________ and ________ were ________ in ________. As they were ________ they ________ and ________. Then they ________. role sidekick response event activity event activity location
45. WHY WE NEED BETTER REQUIREMENTS
46. We can only consider a few things at a time.
47. 7 ± 2
48. 4 – 5
49. Intertwined things must be considered together
50. Complexity undermines understanding
51. What is a good requirement?
52. §  Valuable §  Concise §  Design-free §  Attainable §  Complete §  Consistent §  Unambiguous §  Verifiable §  Atomic §  Understandable
53. Clear, unambiguous definition of done
54. Value comes from understanding . . .
55. Value comes from understanding
56. There is no difference between requirements and understanding
57. Common understanding Stakeholder Analyst & UX Developer Tester User
58. Functional requirements are best understood . . . in context with actors, actions, and results
59. Functional requirements are best understood . . . as Stories
60. D A D D Y !
61. You  &  your  condiGon   What  you  do   What  you  see  
62. You  &  your  condiGon   Context   What  you  do   What  you  see   Event   Response  
63. You  &  your  condiGon   Context   What  you  do   What  you  see   Event   Response   When Given Then
64. ACCEPTANCE CRITERIA AS GIVEN – WHEN – THEN
66. Given is Personable
67. When is Actionable
68. Then is Visible
69. Behavior
70. Conversation
71. Misunderstanding
72. “Hi, Grandma”
73. Design free
74. A first example
75. §  Origin & Destination §  Date §  Seats §  Name & credit card
76. §  Given: I want to fly to the Bahamas §  When: I select my travel city pair §  Then: I see the dates available §  Given: §  When: §  Then:
77. §  Given: I see the available travel dates §  When: I choose my travel date §  Then: I see how many seats are available
78. SCENARIOS
79. Examples … are provable
80. Examples … amplify what we know
81. Examples … point out holes
83. Given: I have chosen a travel itinerary When: I submit my name and payment information Then: I see a confirmation #
84. Travel itinerary Origin Dest Pass Date Name Victoria Bahamas 1 Nov 15, 2014 Robin Submit Itinerary Payment confirmation Valid Good Display “Congratulations, Robin. You are ready for your trip! Your confirmation numbers are NNNNNN” Conf# 000001 Then When Given  
86. §  Multiple travelers §  Invalid itinerary §  Missing payment info §  Confirmation failure
87. Given: I have chosen a travel itinerary When: I submit my name and payment information Then: I see a confirmation #
88. Origin Dest Pass Date Name Victoria Bahamas 1 Nov 15, 2014 Robin Victoria Bahamas 4 Nov 15, 2014 Dave Bahamas Victoria 5 Nov 18, 2014 Monica Itinerary Payment confirmation Valid Good Valid Good Valid Failure Message Conf# Confirmation 000001 Confirmation 000002, 000003, 000004, 000005 “Please call” Then When Given  
90. The Key to Agile Analysis Starts with Understanding Using Given-When-Then to Write Great User Stories