One of the 12 principles of Agile software development
is: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
is inevitable; everything changes and can change a lot over the lifetime of a project. For some reason, however, a lot of people who decided to go Agile seem to throw control
out of the window. Scrum does a couple of things to help manage change without losing control. Here is one to begin with.
The sprint is the first control, this short period of time when the team has committed all its effort into delivering some business value. What's committed for the sprint should not be altered
. Only when the new feature, function, or defect is so critical that the business is happy to take the loss of work is it truly worthwhile to make a change here, because that is the true cost of derailing a team in mid-flow.
The change should in fact land on the product manager's desk. From there it will be added to the backlog, valued, and prioritized.
With the change in the backlog, if it is sufficiently valuable
and high enough in priority
, it will be picked up in a future sprint. But with knee-jerk requirements, it's all too easy for changes to be seen as less required, and it can be nicer to let them stay at the bottom of the pile.