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