Effective requirements discovery and analysis is a critical best practice for serious application development. Until now, however, requirements and Agile methods have rarely coexisted peacefully. For many enterprises considering Agile approaches, the absence of effective and scalable Agile requirements processes has been a showstopper for Agile adoption. In Agile Software Requirements, Dean Leffingwell shows exactly how to create effective requirements in Agile environments.
Review By: Harry Acosta, PMP 10/25/2011This book is much more than just requirements for agile. I consider it worthy of being the textbook for a software project management class bridging the gap between the project management methodology as defined by the Project Management Institute's A Guide to the Project Management Body of Knowledge and agile and Scrum practitioners. I believe it will help me bring agile principles into the waterfall-driven pharmaceutical software development practices—baby steps, but definitely on the right direction with the guidance provided by Dean Leffingwell in this book.
This book speaks to all software quality engineering students and professionals, from neophytes to waterfall die-hards, extreme programming practitioners, seasoned software project managers, and agile and Scrum masters. I will definitely keep this book in the reference section in my personal library, as it provides a lot of insight and advice that can be applied to real projects when scaling up from the simple team all the way to the enterprise-program level.
I like chapters 11, “Role of the Product Owner,” and 14, “Role of the Product Manager,” where the author clearly explains these dual roles. I also like the methods for estimation and velocity normalization explained in chapter 8, as well as the management of non-functional requirements in chapter 17. The Requirements Analysis Toolkit in Chapter 18 will be especially valuable to software quality engineering newcomers, as it will help them to hit the ground running.
Experienced agile and Scrum practitioners will agree with the eight principles of agile architecture explained in chapter 20. Also, this chapter delves into portfolio management with the last two chapters in the section providing valuable insights on moving to agile portfolio management.
If the author considers marketing this book as a textbook for academia, I suggest adding a section on questions, exercises, and problems at the end of each chapter. With the growth in agile practitioners these past few years, I suspect it will not be long before agile starts to be required as part of project management undergraduate or graduate programs around the nation and not just as an independent field of study.