Presented as a 1-day workshop in conjunction with BAWorld Dallas, February 2015.
User Stories seem like an easy idea. You write down a statement, “As a …, I want …, So ….” Then the team starts developing—except the reality is rarely that simple. In the end, Product Owners and Agile Business Analysts are left with numerous questions as they work to support their teams:
• Are User Stories really a placeholder for a conversation? And if so, how does that work?
• I thought agile didn't need any documentation. What does it mean to write a story and how much should be written?
• What about defects and technical stories, are they stories too?
• What is the difference between requirements and acceptance criteria?
• Why should I use "Given-When-Then?"
• Who should be involved in writing and reviewing requirements?
Whether you write on index cards, post-it notes™, or a software tool like Rally and Jira, User Stories have common elements. This session will answer these questions with practical examples of what's included in a good user story and how they should be used to bring stakeholders and the development team to a common understanding.
• IIBA BABOK, Chapter 9.30 - User Stories
• Agile Extension to the BABOK, Section 4.6.1 - The Delivery Framework, Get Real Using Examples
1. Describe the elements of a good user story
2. Produce requirements written in clear and understandable language
3. Demonstrate functionality meets your requirements with small scenarios