Agile Software Requirements Overview: How To Read This Book

With this book, I’m hoping to tell a somewhat complex story—how to address the challenge of managing software requirements in an agile enterprise that may employ just a few developers building a single product to those employing hundreds or even thousands of software practitioners building systems of previously unseen complexity—in a practical, straightforward and understandable matter.

To do so, the book is written in four parts, the last three of which are dedicated to describing specific agile requirement practices at increasing levels of sophistication and scale.

Part I, Overview: The Big Picture of Agile Requirements in the Enterprise

In Part I, we’ll describe an overall process model intended to communicate the “Big Picture” of how to apply agile requirements practices at the project Team, Program, and Portfolio levels.

We’ll provide a brief history of software methods, describing the evolution from waterfall through iterative and incremental development, to agile and lean. In The Big Picture, we’ll describe an organization, requirements, and process model that works for the team and yet scales to the full needs of the enterprise.

We’ll then provide an overview of the model and illustrate how it can be applied in Agile Requirements for the Team, Agile Requirements for the Program, and Agile Requirements for the Portfolio.

If your need is for an introduction and orientation to the concepts, terms, and general practices of managing agile requirements, this part is intended to stand alone.

Part II, Agile Requirements for the Team

In Part II, we’ll describe a simple yet comprehensive model for managing requirements for agile project teams. This portion of the model is designed to be as lightweight as possible, quintessentially agile, and not encumber the agile teams with any unnecessary complexity and overhead. We’ll introduce the agile team, user stories, stakeholders, users and user personas, iterating, agile estimating and velocity, acceptance testing, the role of the product owner, and, finally, methods for discovering requirements.

If your teams are using agile, this comprehensive, explanatory guide to applying agile requirements is intended for you.

Part III, Agile Requirements for the Program

Part III is intended for those involved in building more complex systems that often require the cooperation of a number of agile teams. We’ll expand the picture and introduce additional requirements artifacts, roles, organizational constructs, and effective practices designed for this purpose. We’ll describe Vision, product and system features, the product Roadmap, the role of the product manager, the Agile Release Train, release planning, nonfunctional requirements, techniques for requirements analysis, and use cases.

If you are a developer, tester, manager, team lead, QA, architect, project or program manager, or development director/executive involved in building systems of this scope, this part is intended for you.

Part IV, Agile Requirements for the Portfolio

In Part IV, we’ll describe the final, Portfolio level, of requirements practices. This level is intended to guide enterprises building ever-larger systems of systems, application suites, and product portfolios. These often require the coordination and cooperation of large numbers (20 or 50 or 100 or more) of agile project teams. We’ll introduce additional requirements artifacts, roles, organizational constructs, and practices designed for this purpose. We’ll describe the role that larger-scale, intentional, system-level architectures play in agile development. We’ll introduce a kanban system for reasoning about how to evolve and, when necessary, re-architect, such systems in an agile manner. We’ll also describe some of the legacy thinking in portfolio and project management and give some suggestions as to what to do about it. We’ll conclude with a final chapter describing investment themes, epics, and, finally, one of the ultimate objectives—agile portfolio planning.

If you are a program manager, development director, system architect, executive, or portfolio manager or planner who is involved in managing investments for a portfolio of products, systems, software services, or IT applications, this part is intended for you.