Twin Cities Quality Assurance Association

Corporate Members: you must have an active membership before you can sign-up for the event (at no charge). Click here to get the contact information of your Corporate Admin to have your information added.

Upcoming events

    • 13 Sep 2018
    • 4:15 PM - 6:00 PM
    • Arrowhead Conference Room, One Meridian Crossing, Richfield, MN 55423
    • 45

    A one-hour overview of how to create testable user stories and acceptance criteria, presented by CheckPoint Technologies.


       Details to follow.


    • 14 Sep 2018
    • 8:00 AM - 4:30 PM
    • US Bank Arrowhead Conference Room - One Meridian Crossings, Richfield MN 55423
    • 4
    Title: Writing Agile User Story and Acceptance Test Requirements (1-day Intensive Seminar Workshop)
    Instructor: Bob Crews (Checkpoint Technologies)

    Date: September 14th 2018
    Time: 8:00AM - 4:30PM
    Location: US Bank Arrowhead Conference Room - One Meridian Crossings, Richfield MN 55423

    Max Class Size: 40
    Fee per Person: $110 (member) | $150 (non-members)

    Registration closes on August 29th 2018

    Refund Policy:
    • 60 days before: full refund
    • 45 days before: 75% refund
    • 30 days before: 50% refund
    • After August 29th: no refund

    Everyone complains that poor requirements are the major cause of project problems. Yet, like the weather, nobody does much about it, at least not effectively. Traditional approaches advocate writing voluminous requirements documents that too often don’t seem to help much and may even contribute to difficulties. Agile goes to the opposite extreme, relying on brief requirements in the form of three-line user stories that fit on the front an index card and a few user story acceptance criteria that fit on the card’s back. Surprise, as Mark Twain noted, in some ways it’s even harder to write Agile’s brief requirements effectively. This interactive workshop reveals reasons user stories and their acceptance tests can fall short of their hype, explains critical concepts needed for effectiveness, and uses a real case to provide participants guided practice writing and evaluating user stories and their acceptance criteria/tests. 

    Participants will learn:
    • Major sources of poor requirements that cause defects, rework, and cost/time overruns. 
    • How Agile user stories and their acceptance criteria/tests address these issues. 
    • Difficulties that still afflict requirements in Agile projects and why they persist. 
    • Writing more effective user stories and acceptance criteria/tests. 
    • What else is necessary to produce working software that provides real value. 

    WHO SHOULD ATTEND: This course has been designed for product owners, analysts, developers, and other Agile (and other) project team members who are or should be involved in defining requirements. 

    PREREQUISITES: There are no prerequisites/expectations as to what participants have and have not learned/experienced. It is assumed they have none regarding being assigned to Agile projects. The class establishes how attendees write Agile User Stories now and works progressively to provide them practice in several improvement techniques likely new to them.

    CLASS FORMAT: The class is very interactive and heavily focused on exercises (done in groups) as a learning experience. There’s little in way of printed materials and workbooks.

    Agile Manifesto’s relevant points
    Characterization of traditional approaches 
    Waterfall and big up-front requirements 
    Agile’s sprints and backlogs alternative 
    Agile project team roles 
    User story “As a <role>…” (Card) 
    User story acceptance criteria (Confirmation) 
    Estimating user story size 
    Splitting and refining
    Prioritizing and allocating to backlogs/sprint 
    Constructing/implementing (Conversations) 
    Reviewing, retrospectives 
    Grooming backlog and reprioritizing 
    Exercise: Write Needed User Stories 
    Exercise: Define their Acceptance Criteria 
    Exercise: Review Your User Stories/Criteria

    User stories are backlog items, features
    Chicken and egg relation to use cases 
    Issues and inconsistencies 
    Business vs. product/system requirements 
    “Levels Model” of requirements 
    Other mistaken presumptions 
    Requirements overview 
    Where user stories should fit, do fit instead 
    Conversation conundrum 

    Problem Pyramid™ tool to get on track 
    Exercise: Using the Problem Pyramid™ 
    Exercise: Business Requirement User Stories 
    Issues identifying requirements 
    Product owner and business analyst roles 
    Project team participation 
    Dictating vs. discovering 
    Data gathering and analysis 
    Planning an effective interview 
    Controlling with suitable questions 
    Then a miracle occurs… 

    Missed and unclear criteria 
    Turning criteria into tests, issues 
    How many tests are really needed 
    Test design techniques 
    Checklists and guidelines 
    Decision trees, decision tables 
    Boundary testing 
    Testing is main means to control risk 
    Defects and new user stories 
    Testing that user story focus misses 
    Reactive vs. proactive risk analysis 
    Given, when, then format 
    Exercise: Write User Story Acceptance Criteria 
    Exercise: Design their Tests 
    Exercise: Review Your User Stories/Tests
    • 11 Oct 2018
    • 4:15 PM - 6:00 PM
    • Moneygram Tower, Suite 130, 1550 Utica Ave, St. Louis Park, MN 55416
    • 45

    A one-hour overview of best practices for open source automated testing of desktop and mobile applications, presented by Leo Laskin - with food and beverages sponsored by Sauce Labs.   Details to follow.   


    • 08 Nov 2018
    • 4:15 PM - 6:00 PM
    • Arrowhead Conference Room, One Meridian Crossing, Richfield, MN 55423
    • 45

    A one-hour overview of how to create automation within a BDD approach.  Presented by Otabek Atadjanov.   

    Details to follow.   


© Twin Cities Quality Assurance Association (TCQAA) a 501c(3) organization. All Rights Reserved.

Powered by Wild Apricot Membership Software