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

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.

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

Jeffrey

February 05, 2015
Tweet

More Decks by Jeffrey

Other Decks in Technology

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