Write Right Agile User Story and Acceptance Tests Right – 2-day Intensive Seminar Workshop

Canceled!

Fall 2018

Write Right Agile User Story and Acceptance Tests Right – 2-day Intensive Seminar Workshop

Date: Tuesday, December 18 and Wednesday December 19, 2018

Time: 8:00am – 5:00pm

Decision date: Tuesday, December 11, 2018

Early Registration Date deadline: Tuesday, December 4, 2018

Before Early Registration Date:

Members $445
Non-members $465

After Early Registration Date:

Members $465
Non-members $485

WHERE: Crowne Plaza Hotel, Woburn

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
Exercise: Re-review Your User Stories
Exercise: Re-review their Acceptance Criteria
Exercise: Write another User Story
Exercise: Review Your New User Story

WRITING MORE SUITABLE USER STORIES
Focus on what provides value
Users, customers, and stakeholders
Exercise: Identify Overlooked Stakeholders
Problem Pyramid™ tool to get on track
Exercise: Find Value
Exercise: Using the Problem Pyramid™
Exercise: Business Requirement User Stories
Issues identifying requirements
Exercise: Size a User Story
Strategies for splitting user stories
Exercise: Split a User Story

AND USER STORY ACCEPTANCE TESTS
Confirming vs. defining requirements
Suitability of using for quality factors
Differences from test-first unit tests
Missed and unclear criteria
Turning criteria into tests, issues
How many tests are really needed
Given, when, then format
Exercise: Write User Story Acceptance Criteria
Exercise: Design their Tests
Exercise: Review Your User Stories/Tests

TESTING CONCEPTS
Should tests equal requirements
How testing actually works
Defining correctness independently
Test-first illusion
UAT vs. User Story Acceptance Test
Demo illusory UAT
Test design techniques
Checklists and guidelines
Decision trees, decision tables
Boundary testing
Testing is main means to control risk
Reactive vs. proactive risk analysis
Putting Agile TDD on steroids
Exercise: Applying Proactive Risk Analysis

PRODUCT OWNER VS. BUSINESS ANALYST
Business analysis discovers requirements
Product owner (PO) role created by Agile
Essential PO characteristics
Skills/knowledge for authority
Product owner viewed as the analyst
Should a business analyst (BA) be the PO
Rethinking the PO role
Exercise: Designing a Better PO Role

(HIDDEN) BACKLOG ISSUES
What is a backlog item
What else often also are backlog items
Apples, oranges, and fruitcakes impacts
Different needs and purposes
Different appropriate artifacts
User stories for prioritization on value
Features for product delivery
Tasks for estimating, performing work
Addressing quality factors
Dealing with defects
Agile’s difficulty scaling and integrating
Sprint 0
Spikes
Exercise: Design a Better Backlog

CONVERSATION CONUNDRUM
Placeholder metaphor
Developer as BA, pros and cons
Data gathering and analysis
Planning an effective interview
Controlling with suitable questions
Then a miracle occurs…
Exercise: Design a Better Conversation