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

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

More Decks by Jeffrey

Other Decks in Technology


  1. A bit about you •  Name •  What do you

    know about user stories? •  Something fun or unique
  2. 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?
  3. 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.
  4. 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.
  5. So What’s The Problem? •  What do you think the

    root cause of the frustration is?
  6. 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
  7. 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? ?? ?? ??
  8. 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
  9. 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.
  10. 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.
  11. 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
  12. Where do User Stories come from? •  Product Owner • 

    Team Member •  Analyst •  Anyone
  13. 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
  14. 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
  15. 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  
  16. What’s included? •  User story •  Acceptance criteria •  Business

    rules •  Mock-ups •  Notes •  Description •  Status •  and so on …
  17. 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
  19. 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
  20. Pick a place §  In the forest §  By the

    ocean §  On the roof §  In town
  21. 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
  22. Pick a response §  Say “Not again!” §  Pull a

    biscuit out of your pocket §  Laugh §  Fall into a puddle §  _____________________
  23. Once upon a time _________ and ________ were ________ in

    ________. As they were ________ they ________ and ________. Then they ________. role sidekick response event activity event activity location
  24. §  Valuable §  Concise §  Design-free §  Attainable §  Complete

    §  Consistent §  Unambiguous §  Verifiable §  Atomic §  Understandable
  25. You  &  your  condiGon   Context   What  you  do

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

      What  you  see   Event   Response   When Given Then
  27. §  Given: I want to fly to the Bahamas § 

    When: I select my travel city pair §  Then: I see the dates available §  Given: §  When: §  Then:
  28. §  Given: I see the available travel dates §  When:

    I choose my travel date §  Then: I see how many seats are available
  29. Given: I have chosen a travel itinerary When: I submit

    my name and payment information Then: I see a confirmation #
  30. 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  
  31. Given: I have chosen a travel itinerary When: I submit

    my name and payment information Then: I see a confirmation #
  32. 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