What are User Stories?
User Stories are a great method for expressing stakeholder requirements, whether your projects follow an Agile, Iterative, or a Waterfall methodology. They are the basis for developers to deliver a suitable information technology (IT) app or application.
In today’s parlance, a “complete” User Story has three primary components: 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.
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. 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.
Well-structured User Stories express a single action to achieve a specific goal from the perspective of a single role. When writing User Stories, stakeholders knowledgeable about the role should focus on the business result that the IT solution will enable while leaving technology decisions up to the developers. Good User Stories are relevant to the project, unambiguous, and understandable to knowledge peers. The best user stories also contain crucial non-functional (quality) requirements, which are the best weapon in the war against unsatisfactory performance in IT solutions.
What You Will Get from 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.
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).
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
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
User Stories Defined
- Welcome to the Course Free Preview
- Introduction to User Stories Free Preview
Rules for Writing Effective User Stories
- Rule 1: Keep Your User Story Simple
- Rule2: Express the What, Not the How
- Rule 3: Write Relevant User Stories
- Rule 4: Avoid Ambiguity in Your User Story
- Rule 5: Develop Measurable Non-Functional Requirements
- Rules Review
- What to Do When You Are Done