2-DAY PUBLIC SESSION  |  3-DAY VIRTUAL SESSION

Hands-On User Story Authoring & Elaboration

User Story Training Course Outline

Section I: Remembering Traditional Requirements
Prior to the deep–dive on User Stories, it is important to set context related to traditional requirements documentation and elaboration. Additionally, it is important to understand that authoring and elaborating user stories requires many of the same skills and techniques used when detailing requirements for a waterfall project. During this section we will cover:

  • Types of requirements and business analysis activities
  • Why it is a recipe for failure if you attempt to identify all product requirements at the beginning of a project
  • How traditional business analysis activities align with Agile

Section II: User Story Overview
Agile focuses on the customer, embraces the ever–changing nature of business environments and encourages human interaction in delivering outstanding software. In this introduction, we'll discuss the following:

  • What is User Story including it's parts and components
  • What Acceptance Criteria are and why they are critical to a user story's success
  • The benefit of articulating requirements as user stories
  • How user stories fit into the Agile framework

Section III: Pre–Conditions for User Stories
Before an Agile team can begin writing and elaborating user stories there are things that must be in place. During this section we will set the stage for future class exercises by creating a shared understanding of the following:

  • A sample product vision
  • A sample product roadmap
  • Sample product user roles

Section IV: Writing User Stories Well
In order for an Agile team to succeed it is critical for the product backlog to be populated with well-written user stories. During this section participants will engage in discussion and hands–on activities that cover the following topics:

  • Characteristics & Attributes of Well Written Stories
  • Functional vs. Non–Functional Requirements
  • Aspects of quality Acceptance Criteria
  • Themes vs. Features vs. Epics vs. User Stories
  • Distinguishing between Non–Stories & Spikes

Class Exercises: Based on the Vision, Roadmap and User Roles outlined in the previous section, participants are asked to complete a story-writing workshop.

  • Story Writing Workshop: Based on the Vision, Roadmap and User Roles outlined in the previous section, participants are asked to complete a story–writing workshop.
  • User Story Peer Review: Taking the user stories written during the story–writing workshop as well as a list of user stories provided by the instructor, participants pair–up to review stories, iterate on them and ultimately improve upon them.
  • Acceptance Criteria Peer Review: Participants are asked to independently write acceptance criteria for a set of user stories and then pair up for a peer review before presenting acceptance criteria to the entire class for group discussion.
  • User Story Decomposition: Participants are given a set of user stories in addition to the stories they have produced and are lead through the steps to assess the size of the story and the ability to slice it into smaller stories.
  • Story Type Identification: Participants are given a set of stories to review. They are asked to identify the type of story (User Story, Non–Story, Spike) as well as re—write any stories that are camouflaged to be another type of story.

Section V: Supporting &Elaborating User Stories
While a Product Backlog of user stories is a complete list of desired elements, or requirements, for the product – it is not a complete Requirements Specification. User stories alone are not enough. In this section we will discuss a variety of requirements modeling techniques teams can use to provide the right level of detail needed for successful product delivery.

  • Assumptions, Constraints &Dependencies
  • Business Rules Analysis
  • Data Dictionary &Glossary
  • Data Modeling
  • Scenarios &Use Case Modeling
  • Context Diagrams

Class Exercises:

  • Words are Not Enough: After following a set of instructions provided to the entire class, participants gain an understanding that words alone are not enough for providing requirements detail.
  • Abstracting Business Rules: Participants are provided a set of user stories and supporting documentation and asked to abstract the business rules as well as brainstorm and identify new business rules.

Section VI: Techniques for Identifying User Stories
It is not enough for a Product Owner & team to take a brainstorming approach to writing user stories. There are a variety of standard business analysis techniques that can be used to help build a comprehensive backlog. The techniques that will be discussed include:

  • Document Analysis
  • Benchmarking
  • Interface Analysis
  • Prototyping
  • Decision Analysis
  • Process Modeling
  • Functional Decomposition
  • Story Mapping

Class Exercises:

  • Process Modeling & Decomposition: Participants are provided a basic scenario and asked to model a business process and then use the technique of story mapping to decompose the process into user stories.

Section VII: Preparing for & Executing Iterations
There is an appropriate level of detail about the user stories that is needed for a team to properly complete Iteration Planning activities on Day 1 of an iteration. During this section we will discuss strategies for ensuring the user stories in your product backlog are ready for execution.

  • Backlog Grooming
  • Story Writing Workshops
  • Story Grooming Workshops
  • Story Review Sessions
  • Requirements Verification vs. Validation
  • Determining what & how much to document

Section VIII: Alignment with Traditional Requirements
User Stories are most certainly a transformation in the way software professionals approach requirements. During this section we will begin a review of the course curriculum by comparing strategies for writing user stories with traditionally defined requirement types and business analysis techniques.


Section IX: Retrospective on User Stories
Using Agile Methods – Retrospectives are a key practice in Agile. We will take an opportunity to review our learning collectively and how we can improve.

Class Exercises:

  • Success Factors: Participants review and discuss each success factor identified on Day–1 of the course in order to determine if each individual's objectives were met.
  • Improvement Plans: Participants answer three specific question in order to explore techniques and strategies they plan to leverage as soon as they are back on the job.
  • Course Feedback: Participants answer three specific questions about the course in order to provide the instructor with insight about the course curriculum and delivery of the class in order to improve future classes.

Section X: Real&daWorld Practice
Taking the learnings from the course, we apply techniques and strategies to requirements and examples provided by participants.

Class Exercises:

  • Story Creation & Grooming Workshop: Participants are asked to provide real–world requirements or user stories that the class can critique and collaborate on.