User stories are often misunderstood as lightweight requirements, given by the business stakeholders to the delivery team. This misunderstanding leads to stories being collected in a task management tool, with a ton of detail written down by business representatives. Except in the very rare case where the business representative is also a technical expert and has a great vision for the product, this division of work prevents organisations from reaping the benefits of user stories.
To make things crystal clear, if a team passively receives documents in a hand- over, regardless of what they are called and whether they are on paper, in a wiki or in a ticketing system, that’s not really working with user stories. Organisations with such a process won’t get the full benefits of iterative delivery. User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions. When domain and technical knowledge is spread among different people, a discussion between business stakeholders and delivery teams often leads to good questions, options and product ideas. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made.
Effective discussions about user needs, requirements and solutions become critically important with short delivery phases, because there just isn’t enough time for anyone to sit down and document everything. Of course, even with longer delivery phases documenting everything rarely works, but people often maintain a pretence of doing it. With delivery phases measured in weeks or days, there isn’t enough time to even pretend. When a single person is writing and documenting detailed stories, the entire burden of analysis, understanding and coordination falls on that person. This is not sustainable with a rapid pace of change, and it creates an unnecessary bottleneck. In essence, the entire pipeline moves at the speed of that one person, and she is always too busy.
This book will help you write better stories, spot and fix common issues, split stories so that they are smaller but still valuable, and deal with difficult stuff like crosscutting concerns, long-term effects and non-functional requirements. Above all, this book will help you achieve the promise of agile and iterative delivery: to ensure that the right stuff gets delivered through productive discussions between delivery team members and business stakeholders.
This is a book for anyone working in an iterative delivery environment, doing planning with user stories. The ideas in this book are useful both to people relatively new to user stories and those who have been working with them for years. People who work in software delivery, regardless of their role, will find plenty of tips for engaging stakeholders better and structuring iterative plans more effectively. Business stakeholders working with software teams will discover how to provide better information to their delivery groups, how to set
Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations, and don’t waste too much time nailing down the details upfront. Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.
This book doesn’t cover the basics of stories. We assume that readers know what Card-Conversation-Confirmation means, what INVEST is and how to apply the basic strategies for splitting user stories. This isn’t the first book you should read about user stories, if those terms are unfamiliar. There are plenty of good basic books out there, so read them first and then come back. Please don’t hate us because we skipped the basics, but there is only so much space in the book and other people cover the basics already well enough.
Gojko Adzic is a strategic software delivery consultant who works with ambitious teams to improve the quality of their software products and processes. Gojko won the 2012 Jolt Award for the best book, was voted by peers as the most influential agile testing professional in 2011, and his blog won the UK Agile Award for the best online publication in 2010. To get in touch, write to gojko@neuri.com or visit gojko.net
David Evans is a consultant, coach and trainer specialising in the field of Agile Quality. David helps organisations with strategic process improvement and coaches teams on effective agile practice. He is regularly in demand as a conference speaker and has had several articles published in international journals. Contact David at david.evans@neuri.com or follow him on Twitter @DavidEvans66
