Requirement Changes Are Put Into The Product Backlog

Agile welcomes changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.

Short feedback loops in Agile allow the team to get fast feedback and incorporate changes required by the customer and reduce the possibility of the team developing the wrong product for too long.

The Product Backlog is dynamic and evolves over the lifetime of the product and requires constant grooming and refinement.  The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.

During an iteration, the Agile Team should invest some time to work with the Product Owner to refine the Product Backlog (a.k.a. Product Backlog Grooming).  This includes requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items.  Priorities can change and requirements can move up and down in the Product Backlog.  When new items are discovered, they are inserted into the Product Backlog causing the lower ones to move down the list (and possibly fall outside of the scope of the release) or old requirements removed as appropriate.

Although Agile welcomes changes, when using time-boxed delivery like Scrum, there are no changes allowed during the iteration, and the end date of the iteration does not change.  In return for not making changes during the current iteration, the Product Owner can make any changes they want to the Product Backlog before the start of the *next* iteration.  The Product Owner can add, remove, reorder, or change items before the start of the next iteration.  This enables the Agile team to make and keep commitments, it gives the team focus and stability during the iteration, and it trains the Product Owner to clearly think through what is in the Product Backlog.  Due to the short time-boxes, the team should be able to get some reasonable certainty into the planning and requirements and avoid churning during an iteration.

Overtime if you find that the Product Owner keeps needing to change requirements mid-iteration, then perhaps the iteration length is not short enough.  Plan iteration durations around how long you can commit to keeping change out of the iteration.