User stories can be considered as the most used form to manage requirements in Agile. However, as often with agile concepts Agile that look simple in theory, using them in practice generates many questions: What should user stories contain? When should they be ready to be developed? What is an optimal backlog size? This is the type of issues that Allan Kelly discusses in his interesting Little Book about Requirements and User Stories.
The Little Book about Requirements and User Stories of Allan Kelly explores the many dimensions of user stories and Agile requirements. From the business value to nonfunctional requirements, from the ideal backlog size to acceptance criteria, each topic is discussed clearly in a 3-4 pages section that makes it easy to read and grasp. An essay about the differences between requirements and specifications plus a user story FAQ complete the book.
I recommend this book to every people working in an Agile software development context, as this is a topic that concerns everybody: product owner, scrum master and developers/testers. Business analysts and project managers working in traditional project management organizations will also find in this book insightful ideas about requirement elicitation and management.
Reference: A Little Book about Requirements and User Stories – Heuristics for requirements in an agile world, Allan Kelly, http://leanpub.com/userstories, ISBN 978-0-9933250-5-2
Buy this book at a 50% discount using discount code “ScrumExpert” or the link https://leanpub.com/userstories/c/ScrumExpert
Quotes
Many traditional requirements engineering and elicitation techniques are still valid in agile; it’s just the results don’t end up in a big document. Agile emphasizes just-in-time requirements rather than upfront preparation. The requirements person – be it the product owner, business analyst, product manager, or someone else – embodies the understanding of what is needed, and the user story represents the work that needs doing.
I have two golden rules for user stories. The first is that each story should be beneficial to the business. Ideally, it should carry a statement of value—of course, not all benefits have a financial value, so it is better to talk about business benefit than business value. The second golden rule is: Each story should represent a small piece of work. While it’s tough to define how small “small” is, basically, the piece of work should be deliverable sometime soon.
One of the things teams typically find difficult is making stories small. Getting pieces of work that then can be delivered in a few days and demonstrate business benefit is undoubtedly hard. And when you’ve not done it before, it’s harder still! Acceptance criteria, or ACs, have a role to play here. Each individual criterion is potentially a story in its own right.
Placing only effort estimates on stories means story selection is usually based of minimum effort, or what fits within the time or budget remaining. Without understanding value, that “biggest bang” might not end up being so lucrative after all. Things get really factious when developers point out how difficult it is to come up with a realistic estimate. Even in the absence of value estimates, business representatives are quick to say, “But how can we do cost benefit analysis without the cost?” The bottom line is you can only do cost-benefit analysis if you have estimate for both the cost and the benefit.
How do you handle non-functional requirements such as content (e.g. the exact wording on a web page, the content of an email that gets sent as part of a registration process)? If the content of the email is not provided in the requirements *before* the developers start work on the PBI, when should it be provided, and will waiting for it to be provided stall development work at In Progress?
The book has a section about non-functional requirements. In summary, Allan recommends either to write user stories for them or to add the constraints to actual user stories. On this topic, I also recommend the article Non-Functional Requirements: Do User Stories Really Help? written by Rachel Davies and published on Methods & Tools.