How to Write and Manage User Stories to Communicate Business Needs

Capture, Clarify, and Confirm User Stories, Acceptance Criteria, Scenarios, and Examples that Communicate Business Needs to Agile Teams

Classroom Live ONSITE – Duration: 2 days (14 PDU/CDU)
Classroom Live ONLINE – Duration: 2-5 days (14 PDU/CDU)
Public Schedule

Some of this content is also available in our eCourses, Books, and FREE KnowledgeKnuggets™

Course Overview

User Stories: From the CARD to the CONVERSATION to the CRITERIA

User Stories support efficient communication among all parties interested in getting to the right technology solution. They make your requirements elicitation effort easier without adding an extra burden of effort. This exercise intensive workshop presents 25 business analysis techniques for each of the three parts of User Stories, namely

  • the CARD (Business Needs and Wants),
  • the CONVERSATION (Developer-level Requirements),
  • the CRITERIA (Acceptance Criteria, Scenarios, and Examples).

These three parts are critical for successful implementation of “lean” software development philosophies.

The CARD expresses a business need. Domain experts representing the user community express their goals, objectives, and wants in business language. This gets the User Story into a backlog and allows the business to prioritize its technology needs. Together with the technical team, they create early estimates. The main purpose of the CARD is to trigger a CONVERSATION between the business and technical teams.

The CONVERSATION occurs when a developer is ready to code the story. Business and technical teams add details to ensure a common understanding of each User Story as work progresses. This requires business analysis techniques like requirements analysis, process modeling, data modeling, use case writing, etc.

The CRITERIA confirm that the solution delivers what the SME intended. User Stories form an essential bridge between requirements and testing to support Acceptance-Test-Driven Development (ATDD) and Behavior-Driven Development (BDD) methodologies.

About Our Instructors

Tailored Business Analysis Training
We Tailor the Content to Fit Your Needs

At no cost to you, we can assemble an optimal set of training topics based on your group’s current and desired business analysis skill levels. We can also use our Business Analysis Skills Evaluation (BASE) tool to establish these levels. 

or call 702-625-0146

Target Audience

  • Product Owners
  • Business Analysts
  • Requirements Engineers
  • Business- and Customer-side Team Members
  • Agile Team Members
  • Subject Matter Experts (SME)
  • Project Leaders and Managers
  • Systems Analysts and Designers
  • AND “anyone wearing the business analysis hat”, meaning anyone responsible for defining a future IT solution

Learning Outcomes

Upon successful completion of this skill-building experience, you can:

  • Describe the benefits and purpose of expressing business needs in User Story form
  • Minimize missing business needs by identifying stakeholders
  • Avoid misinterpretation by writing role-based User Stories
  • Learn 5 different elicitation techniques to discover more User Stories
  • Apply INVEST, DEEP, and other guidelines to verify the quality of your User Stories
  • Capture the acceptance criteria for testing a well-formed User Story
  • Right-size (group or split) Epics and User Stories to expedite development
  • Use best-of-breed business analysis techniques to enhance communication between business and technical teams
  • Decompose User Stories to expose functional specifications and non-functional requirements
  • Translate acceptance criteria into Scenarios, Scenario Outlines, and Examples for effective acceptance and regression testing

Detailed Course Outline

1 Introduction to User Stories

  • The User Story Advantage
  • Current Software Development Approaches
  • Lean Business Analysis Concepts
  • A Backlog Hierarchy
  • Business Analysis in Lean/Agile SDMs
  • Exercise: Your User Stories

2 The CARD: Techniques for Gathering User Stories

  • A User Story Is Role-Based
  • Initial Stakeholder Identification
  • Adding Role Details
  • A Vision Statement Reveals Roles
  • Exercise: Defining Role Parameters
  • Getting to User Stories
  • Exercise: Traits of “Good” Elicitors
  • The 4 C’s of Non-Verbal Communication
  • 5 Types of Elicitation Meetings
  • Story Writing Workshops
  • Listening Techniques
  • Exercise: Dealing with People Issues
  • Rules for Effective User Stories
  • Common User Story Structures
  • Exercise: Comparing the Structures
  • Keep Your User Story Simple
  • Focus on What Not How
  • Maintain Story Relevance
  • Properties of Good User Stories
  • INVEST in Your User Stories
  • Exercise: Dependent Stories
  • Business Values Are User Goals
  • Exercise: Capturing User Stories
  • User Story Sizing Parameters
  • Value Measurement: Right-Sized
  • Exercise: Right-Sizing Your User Stories

3 The CONVERSATION: From User Story to Code-able

  • User Stories are NOT Always Simple
  • Reducing Complexity in User Stories
  • Cynefin Combats Uncertainty
  • Remove Ambiguity and Subjectivity
  • Be Specific to Clarify Content
  • Acceptance Criteria Add Clarity
  • Grouping User Stories Reveals Issues
  • Value of Grouping User Stories
  • Potential Pitfalls in a Group of User Stories
  • Identifying Duplicated User Stories
  • Discovering Conflicts between User Stories
  • Exercise: Inconsistent User Stories
  • Taking a Deep-Dive into Your User Story
  • Getting to Functional Specifications
  • Exercise: User Story Splitting
  • Extracting Data from User Stories
  • Defining Data Element Accuracy
  • Precision and Currency of Data Elements
  • Non-Functional Requirements
  • Non-Functional Characteristics
  • Evaluating Performance Requirements
  • Discovering Business Rules
  • Identifying Constraints
  • Considering Volatility and User Experiences
  • Exercise: Measurable vs. Subjective NFRs
  • Stamping Out Subjectivity
  • User Story Decomposition Revisited

4 The CRITERIA: Acceptance or Business-Facing Testing

  • Moving from Acceptance Criteria to Scenarios
  • Scenarios Are Final Requirements
  • Defining Acceptance Tests
  • Introducing Gherkin (Given-When-Then)
  • Capturing Scenarios and Scenario Outlines
  • Using Examples and Test Data Engineering
  • Discovering Scenarios
  • From User Stories to Scenarios
  • Using Decision Tables
  • Finding Scenarios by Decomposition
  • Getting from Use Cases to Scenarios
  • Scenarios for NFRs

5 From Showtime to Go Time!

Personal Improvement Plan

  • Personal Improvement Plan (PIP)
  • Understanding the Learning Curve
  • Developing Your PIP