Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

77d585b881102ee229be5d5af4a11b8b?s=47 Jeffrey
February 05, 2015

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.

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.

• 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



February 05, 2015


  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

  5. None
  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?
  11. None
  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

  19. What is a User Story? •  Card •  Conversation • 

  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

                                  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:

  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


  36. None
  37. None
  38. Pick a role §  Princess §  Fireman §  Singer § 

  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

  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

  65. None
  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

  79. Examples … are provable

  80. Examples … amplify what we know

  81. Examples … point out holes

  82. None
  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  
  85. None
  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  
  89. None
  90. The Key to Agile Analysis Starts with Understanding Using Given-When-Then

    to Write Great User Stories