One of the main goals of Scrum is to over-perform traditional and waterfall-like project management frameworks when dealing with requirements. The complexity of finding out what a system has to do and how, is far from being trivial. Assuming that the system requirements can be determined at the very beginning of the project is considered today a very naive approach that relies, at least, in two fallacies. First, that the client knows what she or he wants the system to do. Second, that this is the right thing to do, and that is not going to change during the development of the project.

However, the reality is that these two assumptions are far from being true. First, the client use to have just a vague idea about what the system has to do, or most of the time, an idea about a business opportunity that needs to be covered. And second, this idea evolves with time, based on the results of the project itself, and on changing market needs. That is, the target that represents the “definitive” system characteristics is moving, sometimes under unknown conditions.

Trying satisfy a software project requirements with a single and initial analysis phase, is like trying to hit a randomly moving target with a predetermined and single set of trajectory parameters. Is very unlikely that we will hit that target. Instead, it is better to periodically update the trajectory based on the target position. This is what adaptive control systems do.

Similarly, Scrum, and other agile iterative processes, introduce the concept of sprint and periodical review and planning meetings, that together with product backlogs and how Product Owners deal with them, emulates the periodicity and parameter estimation mechanisms that adaptive control systems successfully use. Thankfully, these iterations are time-boxed. The requirements of what has to be delivered at the end of the sprint, cannot change during its duration. This allows the development team to focus and achieve something periodically. It gives time to see periodical results used to take further decisions about the requirements, the same way that an adaptive control system gets stability avoiding too frequent controlling actions. They key here is to find the right periodicity, the right sprint duration.