Fans pick 70 books like User Stories Applied

Suzanne and James Robertson have been writing insightful books on software requirements for many years. This book covers all the important topics, including understanding the real problem, different techniques for exploring solutions, and numerous ways to communicate requirements effectively. I especially like their treatment of quality attribute requirements and defining “fit criteria” to judge whether a solution adequately addresses them.

The book includes a comprehensive requirements specification template to guide writing a rigorous and complete specification on projects for which that is valuable. I also appreciate their use of visual models both to communicate with the reader and to guide the reader in communicating requirements to project stakeholders. I do prefer my book Software Requirements, but this is an excellent choice as well by two authorities in the field.

Exploring requirements is more about communication than computing. Requirements elicitation often involves discussions between business analysts and user representatives or other project stakeholders in either one-on-one discussions or group workshops. Requirements by Collaboration presents a wealth of practical tools and techniques for planning and leading requirements development workshops. It’s packed full of useful tips, checklists, questions to ask, and activities to perform to make workshops effective and successful.

I especially like Gottesdiener’s “collaboration patterns,” eight techniques that a workshop facilitator can employ to help the group achieve its objectives. The pattern called Decide How to Decide is the first one that any group of collaborators should use: exactly how will we make decisions? If you expect to lead, or even participate in, requirements workshops, read this book first.

Most discussions about requirements focus on functionality, which is what the users most obviously observe in a software system. However, user satisfaction also depends heavily on nonfunctional requirements, such as various quality characteristics the system exhibits: usability, availability, reliability, security, scalability, maintainability, and others.

The Quest for Software Requirements is the only book that focuses on nonfunctional requirements. It provides many questions a business analyst could ask during requirements elicitation to understand the stakeholders’ expectations for those all-important quality attributes. That’s an often-neglected aspect of requirements exploration that frequently leads to deficiencies that can be expensive to correct later in development or after the product is released. This book can help you avoid those unpleasant outcomes.

I recognized the value of use cases the first time I used them successfully on a project. Some years later I developed a 1-day training course on use cases. I read four of the most popular use case books then available, cover to cover, one right after the other. Use Cases: Requirements in Context did the best job of presenting a practical approach to applying the use case technique. 

Shifting the requirements focus from system features to a usage-centric viewpoint provides many benefits, and use cases are the best way I’ve found to approach that. They provide an organizational structure for grouping related information relating to how users will interact with the system to perform tasks. This book describes a solid way to apply the use case technique.

“Good agile testing is good context-driven testing applied in an agile context.”

The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.

These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.

Many of us have fully embraced agile programming, but doing it well, really well, requires discipline. In Clean Agile a number of world-class programmers discuss what it takes to put Agile programming into practice with y our team. This book has made me a much more “agile” agile programmer, and the section on SCRUM is worth the price of the book.

Patton’s book is an amazing introduction to modern product management techniques, both from a practical and theoretical view. It introduces story mapping as a practical technique that you’ll be able to use immediately to start making sense of large plans and visualizing product ideas. More importantly, Patton uses this technique as an excuse to introduce readers to principles such as focusing on outcomes over outputs, working closely with users and iterative delivery, and experimentation. 

The book is a gateway drug for new product managers. It is an easy read and will get you hooked on modern ways to ensure that both users and stakeholders get value from your products. It helps people get started easily in a new role and provides a great foundation for going deeper into this field.

This is the most recent book I'm recommending, and it’s also more than just a book on Test-Driven Development. I often proclaim that Test-Driven Development and software design are two sides of the same coin. One cannot separate one from the other. So learning about Test-Driven Development also means that one has to learn about software design principles. This book teaches both. The first part of the book is all about Test-Driven Development, while the remainder of the book also touches on object calisthenics, refactoring, code smells, design patterns, the S.O.L.I.D. principles, connascence, the four elements of simple design, and much more. Whether you’re new to programming software, or whether you’re a seasoned developer, there’s much to learn from this book.      

The second book from Gregory and Crispin brought me up-to-date on the different trends in the Agile world, ten years after having delved into their first book.

How do you share the quality mindset in a DevOps culture? What about Design Thinking? With many more examples from the industry, the two authors made me curious about some of the things that I had ignored until I read their book.

While this book was still in the writing, Crispin and Gregory published draft chapters on the internet.

At the time, I read them, and managed to introduce many of the great insights into my own work. Even though I was working in a more traditional environment, the ideas from the two ladies inspired me on my journey to the agile methodologies.

I even managed to contribute some of my own real-world examples from my own experiences to their writings – and they decided to include some of them.