Change Control

Change control starts on Day One of an agile project! In two-way dialog with the user, customer or executive sponsors, the agile team elicits requirements in the form of feature requests and user scenarios. These requests may be for brand-new functionality, or for changes or additions to already implemented functionality. Developers estimate each requested chunk of functionality, and the customer then gives priorities for the features to work on over the next iteration.

Agile iterations are typically short (two to twelve weeks), so there aren't usually many features to track for a given iteration. Requirements are managed by keeping track of the list of features for the current iteration, and a current backlog of requested but not yet implemented features. At the end of an iteration, the current backlog of requests, along with any new requests, are once again prioritized by the customer so that the developer can decide which set of features will be worked on during the next iteration.

This frequent reprioritization and selection process is the most common agile equivalent of a change control board (CCB). The customer drives the priorities and need for change while development accommodates those needs as much as possible in each iteration, focusing almost exclusively on the features for the current iteration.

In some cases, the features or change requests are written to the change-control system. In more informal projects, particularly Extreme Programming projects, requests are documented on a four-inch by six-inch white index card or two-foot by four- foot flipchart taped to the wall, whose text is updated throughout the iteration period, so that everyone who reads it sees the original request and the modifications that have been made to it.