Agile methods were invented to deal with changing requirements, and they treat requirements very differently than traditional software engineering methods. This book brings together various means of eliciting, stating, validating, and managing requirements in Scrum, the premier agile method. Although little here is new, the book does aggregate ideas about managing requirements from several sources and fits them together into a coherent process that takes advantage of existing tools.

This volume is slim, coming in at only 151 pages for the main text, along with another 20 or so pages for the contents, preface, acknowledgements, a short glossary, and an index. This brevity is achieved partly through the welcome practice of avoiding the chattiness of many contemporary books on software development. Unfortunately, shortness is also achieved through lack of examples, dense and often impenetrable explanations, and little argument or justification for the positions and practices advocated. The book would be much better with an extra 20 or 30 pages of expanded explanations, justifications, and examples illustrating its points.

The author assumes that readers are familiar with Scrum and agile methods in general. The book begins with a short chapter arguing that agile methods are needed to deal with changing requirements. Chapter 2 discusses the organizational framework for using Scrum. Chapters 3 through 5 recount the standard Scrum techniques of capturing requirements in user stories, placing them in a product backlog, grooming the product backlog, and implementing user stories in short sprints with stakeholder feedback at each step, providing grounds for modifying and elaborating requirements. These chapters feature the term “desirement,” which is not used in the standard way, but is never clearly explained. Although I puzzled over what this term could mean through the entire book, I found that simply treating it as a synonym for “requirement” made most of the text comprehensible.

The last part of chapter 2 and chapters 6 through 8 bring in material augmenting basic Scrum. User experience design, an important topic often ignored in discussions of requirements, is introduced as a means of elaborating product backlog items. Scenarios (which in traditional methods are often called test cases) are introduced as another requirements elaboration technique in chapter 6, along with the introduction of specification workshops as a sprint activity. Chapter 7 introduces domain-specific languages as a means of encoding scenarios to produce acceptance tests that can then be incorporated into test-driven development practices. This is the longest and most technically challenging chapter of the book, and it also contains some of the most impenetrable explanations. Most readers will find it hard going unless they are already familiar with the behavior-driven development tools used in the examples. Chapter 8 suggest a way to introduce non-functional requirements into Scrum. The final chapter is a summary.

The book does a good job bringing together practices for eliciting, stating, validating, and managing requirements in Scrum. Readers unfamiliar with Scrum will have a hard time understanding this book--it is not for beginners. Scrum experts will find a few new ideas, and may benefit from its comprehensive perspective on requirements. Novice Scrum users may find the early chapters helpful in their review of standard material with an emphasis on requirements, but they will likely find large portions of the later chapters opaque as they introduce difficult material with poor explanations and cursory examples.

More reviews about this item: Amazon