The term “User Story” is a relative new addition to our language and its definition is evolving. They have already proven to be a great structure for expressing Stakeholder Requirements, whether your projects follow an Agile, Iterative, or a Waterfall methodology. In today’s parlance, a complete User Story has three primary components, namely the “Card”, the “Conversation”, and the “Criteria”. Different roles are responsible for creating each component. The “Card” expresses a business need. Domain experts representing the user community are responsible for expressing the business need.
The “Conversation” is an ongoing discussion between a developer responsible for creating software that meets the business need and the domain expert(s) who defined it (e.g., the original author(s) of the “Card”). The developer initiates the “Conversation” with the domain expert(s) to define the “Criteria” and get any additional information the developer needs to create the application. This “Conversation” takes place immediately before the developer(s) start to write the software, meaning there can be a significant time delay between the creation of the “Card” and the “Conversation”. There is much to be written about both the “Conversation” and the “Criteria”, but neither component is dealt with in any detail in this course. A well-written User Story (“Card”) can drastically reduce the time needed for the “Conversation”. It reduces misinterpretations, misunderstandings, and false starts, thereby paving the way for faster delivery of working software. We chose to limit the content of this publication to the “User Story” as understood by the user community to keep the course focused and address the widest possible audience.
For practical reasons, the “Card” is the User Story from the perspective of the user community. Since we created this course specifically to address the authors of the “Card”, we use the term “User Story” as a synonym throughout the course. This 1-hour video course presents two common User Story structures to help the authors of the “Card” ensure that their User Stories have all the required components needed to express the true business need as succinctly as possible. It offers five simple rules to ensure that their user stories are the best that they can be. That, in turn, will reduce the amount of time needed in User Story elaboration and the “Conversation” with the developer(s).
View Course Outline with Lesson Previews
Anyone involved in capturing and writing User Stories for an Information Technology Solution, including (but not limited to):
- Subject Matter Experts (SME)
- Agile Product Owners
- Business Process Managers
- Business Process Users
- Business Analysts
- User liaison personnel
- and anyone wearing the BA hat
Upon completion of this course, you can:
- Translate business needs into well-structured User Stories
- Writing User Stories that express the what and avoid the how
- Apply five simple rules for writing User Stories
- Clarify assumptions in user stories by adding context
- Identify and remove ambiguous and subjective terms and phrases in User Stories
- Select the appropriate format for writing User Stories for Agile Projects
- Write stakeholder requirements in User Story format that solve business problems
- Elaborate User Stories to identify measurable non-functional requirements