The Agile Pocket Guide: A Quick Start to Making Your Business Agile Using Scrum and Beyond

Chapter 20

Understanding Requirements

One of the many struggles that proponents of Agile face is the changing-requirements churn. The story is the same: funds are allocated to the tune of $3 million, product specs are built out, requirements are built, a timeline is proposed, work begins—and then the Product Owner or stakeholders say they need to change things in the requirements, or the market has changed. You are now in month 9 of a 15-month project. Wow, how did that happen? Fortunately, for many of us, Agile is exactly the approach that manages change very well because it includes a flexible change-management process.

Requirements change for various reasons, as we all know: a stakeholder realizes that she missed a requirement or the requirements are missing a feature, issues and bugs are identified, market demands change, Product Owners don't realize what they actually needed, or just plain old politics create problems. The two greatest points I want to make are that we do not want to prevent change from happening (requirements change!), and we must allow the business or stakeholders to prioritize the changes. To allow the business to change requirements is something that we can adjust for easily. Freezing requirements early in the life cycle prohibits the business from getting what it wants and also guarantees that the development team does not make what the stakeholders want.

An individual Product Owner needs to be the single point of authority and must understand that he ...