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
   

   View Slide

2. @JeffreyGoodReq
   goodrequirements.com
   www.linkedin.com/in/jeffreydavidson
   

   View Slide

3. A bit about you
   •  Name
   •  What do you know about user
   stories?
   •  Something fun or unique
   

   View Slide

4. TRADITIONALLY . . .
   

   View Slide

5. View Slide

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?
   

   View Slide

7. She Felt it Always Seemed….
   Many conversations
   were had.
   Lots of
   documentation was
   produced.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

10. So What’s The Problem?
    •  What do you think the root cause
    of the frustration is?
    

    View Slide

11. View Slide

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
    

    View Slide

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?
    ??
    ??
    ??
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

18. ALL ABOUT USER STORIES
    

    View Slide

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

    View Slide

20. Where do User Stories come from?
    •  Product Owner
    •  Team Member
    •  Analyst
    •  Anyone
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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  
    

    View Slide

24. What’s included?
    •  User story
    •  Acceptance criteria
    •  Business rules
    •  Mock-ups
    •  Notes
    •  Description
    •  Status
    •  and so on …
    

    View Slide

25. What’s a good one?
    Independent
    Negotiable
    Valuable
    Estimable
    Sized appropriately
    Testable
    •  Bill  Wake  
    

    View Slide

26. What kinds are there?
    •  Functional
    •  Non-functional
    •  Technical
    •  Spikes
    •  Tracking
    •  Defects
    •  Epics
    

    View Slide

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
    

    View Slide

28. What do you need to know
    about your product?
    image: discovertodeliver.com
    

    View Slide

29. User Roles
    •  Define who your users are
    T I P :
    NEVER “User”
    

    View Slide

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
    

    View Slide

31. Story Slicing
    

    View Slide

32. Prioritizing
    •  MoSCoW
    

    View Slide

33. Prioritizing
    •  Kano image: mindtheproduct.com
    

    View Slide

34. Prioritizing
    •  Weighted Shortest Job First
    

    View Slide

35. UNDERSTANDING COMES
    FROM TELLING STORIES
    

    View Slide

36. View Slide

37. View Slide

38. Pick a role
    §  Princess
    §  Fireman
    §  Singer
    §  Scientist
    

    View Slide

39. Pick a sidekick
    §  Cousin
    §  Magic pet monkey
    §  Stuffed animal
    §  Talking bird
    

    View Slide

40. Pick an activity
    §  Walking
    §  Flying
    §  Having a picnic
    §  Shopping
    

    View Slide

41. Pick a place
    §  In the forest
    §  By the ocean
    §  On the roof
    §  In town
    

    View Slide

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
    

    View Slide

43. Pick a response
    §  Say “Not again!”
    §  Pull a biscuit out of your
    pocket
    §  Laugh
    §  Fall into a puddle
    §  _____________________
    

    View Slide

44. Once upon a time _________
    and ________ were ________ in
    ________. As they were
    ________ they ________ and
    ________. Then they ________.
    role
    sidekick
    response
    event
    activity event
    activity
    location
    

    View Slide

45. WHY WE NEED BETTER
    REQUIREMENTS
    

    View Slide

46. We can only
    consider a few
    things at a time.
    

    View Slide

47. 7 ± 2
    

    View Slide

48. 4 – 5
    

    View Slide

49. Intertwined things
    must be considered
    together
    

    View Slide

50. Complexity
    undermines
    understanding
    

    View Slide

51. What is a good
    requirement?
    

    View Slide

52. §  Valuable
    §  Concise
    §  Design-free
    §  Attainable
    §  Complete
    §  Consistent
    §  Unambiguous
    §  Verifiable
    §  Atomic
    §  Understandable
    

    View Slide

53. Clear, unambiguous
    definition of done
    

    View Slide

54. Value comes from
    understanding
    . . .
    

    View Slide

55. Value comes from
    understanding
    

    View Slide

56. There is no
    difference between
    requirements and
    understanding
    

    View Slide

57. Common
    understanding
    Stakeholder
    Analyst & UX
    Developer
    Tester
    User
    

    View Slide

58. Functional requirements
    are best understood . . .
    in context with actors,
    actions, and results
    

    View Slide

59. Functional requirements
    are best understood . . .
    as Stories
    
    

    View Slide

60. D A D D Y !
    

    View Slide

61. You  &  your  condiGon  
    What  you  do  
    What  you  see  
    

    View Slide

62. You  &  your  condiGon  
    Context  
    What  you  do  
    What  you  see  
    Event  
    Response  
    

    View Slide

63. You  &  your  condiGon  
    Context  
    What  you  do  
    What  you  see  
    Event  
    Response  
    When
    Given
    Then
    

    View Slide

64. ACCEPTANCE CRITERIA
    AS
    GIVEN – WHEN – THEN
    

    View Slide

65. View Slide

66. Given is Personable
    

    View Slide

67. When is Actionable
    

    View Slide

68. Then is Visible
    

    View Slide

69. Behavior
    

    View Slide

70. Conversation
    

    View Slide

71. Misunderstanding
    

    View Slide

72. “Hi, Grandma”
    

    View Slide

73. Design free
    

    View Slide

74. A first example
    

    View Slide

75. §  Origin & Destination
    §  Date
    §  Seats
    §  Name & credit card
    

    View Slide

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:
    

    View Slide

77. §  Given: I see the available
    travel dates
    §  When: I choose my travel date
    §  Then: I see how many seats
    are available
    

    View Slide

78. SCENARIOS
    

    View Slide

79. Examples …
    are provable
    

    View Slide

80. Examples …
    amplify what we
    know
    

    View Slide

81. Examples …
    point out holes
    

    View Slide

82. View Slide

83. Given: I have chosen a travel
    itinerary
    When: I submit my name
    and payment information
    Then: I see a confirmation #
    

    View Slide

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  
    

    View Slide

85. View Slide

86. §  Multiple travelers
    §  Invalid itinerary
    §  Missing payment info
    §  Confirmation failure
    

    View Slide

87. Given: I have chosen a travel
    itinerary
    
    When: I submit my name
    and payment information
    
    Then: I see a confirmation #
    

    View Slide

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  
    

    View Slide

89. View Slide

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

    View Slide