Writing Agile User Story and Acceptance Test Requirements – Cut Creep Overruns, Disappointment, and Embarrassment

Fall 2017 Course

Writing Agile User Story and Acceptance Test Requirements Register Now

Writing Agile User Story and Acceptance Test Requirements – Cut Creep Overruns, Disappointment, and Embarrassment

Date: Tuesday, December 12, 2017

Time: 8:30 am – 5:00 pm

Decision date: Tuesday, December 5, 2017

Early Registration Date deadline: Tuesday, November 28, 2017

Before Early Registration Date:

Members $220
Non-members $245

After Early Registration Date:

Members $245
Non-members $265

WHERE: Crowne Plaza Hotel
15 Middlesex Canal Park Drive
Woburn, MA 01801
USA
Phone 781-245-5405

email sec.boston@ieee.org

If paying by check, the check must be received before the appropriate dates for Early Registration and Decision Dates.

Make Checks payable and send to:
IEEE Boston Section
One Centre Street, Suite 203
Wakefield, MA 01880

Speaker: Robin Goldsmith, President, GoPro Management

Course Overview:

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.

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 …” (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