Twin Cities Quality Assurance Association

  • Home
  • Writing Agile User Story and Acceptance Test Requirements (1-day Intensive Seminar Workshop)

Writing Agile User Story and Acceptance Test Requirements (1-day Intensive Seminar Workshop)

  • 14 Sep 2018
  • 8:00 AM - 4:30 PM
  • US Bank Arrowhead Conference Room - One Meridian Crossings, Richfield MN 55423
  • 4

Registration

  • If you are not an Individual Member or the employee of Member Corporation, please register using this option.
  • If your company is a Corporate Member of TCQAA, please register using this registration type with a discounted fee.
  • If you have joined as a Member and paid dues for 2018, you may register as a member with a discounted fee.

Public Registration
Register
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

Synopsis: 
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, USER STORY FUNDAMENTALS 
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

REQUIREMENTS ARE REQUIREMENTS — OR MAYBE NOT 
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 

WRITING MORE SUITABLE USER STORIES 
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… 

AND USER STORY ACCEPTANCE TESTS 
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


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

Powered by Wild Apricot Membership Software