“How do I make my user stories smaller?” “What is the right size for a user story?” “What is the difference between an Epic and a Story? And where do Tasks and Sub-Tasks fit in?” “Who writes user stories?” “Why user stories?” "Do I have to use user stories?"
Allan Kelly found himself answering these questions, and similar ones, again and again so...he sat down to write the answers and this book was born.
In this book Allan discusses the role of user they are not requirements, they are tokens for work to be done and a placeholder for a conversation. He gives his two golden stories must be small and they must be beneficial to the business - further he describes what beneficial is, how to put a value on a story, and how to maximize the return on investment.
He gives particular attention to the difference between requirements and specification and how these ideas line up with user stories and acceptance criteria. Along the way he takes epics, tasks, definition of done, backlog structuring, acceptance tests, and much else.
In short, it's a little audiobook about user stories and all that goes with them.
Allan Kelly has held just about every job in the software world, from system admin to development manager by way of programmer and product manager. Today he works helping teams adopt and deepen Agile practices, and writing far too much. He specialises in working with software product companies and aligning products and processes with company strategy.
He is the author of three books: "Xanpan - reflections on agile and software development" (https://leanpub.com/xanpan), "Business Patterns for Software Developers" and “Changing Software Development: Learning to be Agile”; the originator of Retrospective Dialogue Sheets (http://www.dialoguesheets.com), a regular conference speaker and frequent contributor to journals.
Indeed "a little book". You can make it through in two afternoons.
I reached for the book because I have been feeling that User Stories are doing harm to the industry. After few books about product management and Mike Cohn's blog I reached some level, thus the book seemed to be too fundamental.
It lacks the INVEST model, however this is not a big problem as it approaches user stories slicing in a similar way. I think that the author could criticize more on bad user stories which are flooding the backlogs all over the world (clicking on buttons, showing modals, focusing on UI, and neglecting business value). Don't get me wrong - the author writes about value in user stories and talks about the right detail level but he could add 10-20 pages on the bad examples.
The good things now. I liked that the author repeated few times that the user story is a placeholder for conversation and should provoke good and healthy communication during the iteration and gives valid points on that. There were more valuable observations related not only to user stories but analysis, basic hygiene when working with backlog, epics, and specifications. Specification separation from acceptance criteria was the most important thing for me in the book.
Short and useful book with some surprising observations. My favorite:
The business value, that Product Owners assign to a story, will influence the estimate of work. A story assigned a business value of $1M will get one technical solution. The identical in every respect story assigned a business value of $100K will get a very different technical solution. Similarly, estimates of story points/work will impact the assignment of story value. This is the anchoring bias at work.
After project myopia ok started reading this one, I love the way Allan can explain complex stuff in simple ways and giving examples. I have took some important intention here that I can apply right away. Love it
A delightful short and clear description of user stories and the concepts relevant to it. Suitable as a reference guide for those more experienced and helpful for those new to the topic just getting into it. I'll be sharing the book with my team so we can all get up to date on user story principles in our day to day work.