Most iterative software development processes recommend that changes not be introduced during an iteration. The main idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.

To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not assigned for implementation until a future iteration via the work items list.

Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change requests.

One notable exception is a defect discovered during testing that prevents the team from meeting the objectives of the iteration. In this case it is reasonable to assign the work item to the current iteration as this does not represent a scope change, it represents unfinished work.

Consider the following when choosing the future iteration where the change request will be addressed:

• Group similar change requests in the same iteration. For example multiple change requests focused on the same functionality or that are dependent on each other.
• Assign change requests that mitigate high risks to the earliest iteration possible.