In an ideal world, once a team has started an iteration then the iteration plan should not change.
Here are some of the reasons why you shouldn’t change an iteration plan:
- Changes cause churn and additional administration that will negatively impact velocity. Stories that have been started and dropped will have to be rewritten and re-estimated in the next planning session. New stories will probably have to be written and estimated in the middle of the iteration.
- The teams remaining velocity can be difficult to calculate part way through an iteration thus the replanning is likely to mean the iteration is under-planned or over-planned. An under-planned iteration will mean that a third round of planning will have to take place. An over-planned iteration means some stories will not get DONE and they will have to be rewritten and re-estimated in the next iteration …
- The most common Scrum iteration duration of two weeks is a small enough window of time for the business not to have change its mind. Twenty-six opportunities to change your mind in a year should be enough even for the most indecisive product owners.
- Refusing to let the product owner change the iteration plan sends them a clear message that they have to plan better in future because they won’t be allowed to make changes mid-iteration.
- Replanning suggests that there has been a critical failure of planning and prioritisation by the product owner during the planning of the iteration. This should be talked about in the retrospective.
- It’s not good for team moral to change the plan/stories that they worked hard to create and have committed to.
- It will distort any Scrum metrics that you are capturing eg story points done, which are useful for calculating velocity.
- It’s part of the scrum masters job is to protect the team from forces outside the team eg indecisive business people.
That said there will always be exceptions any good rule. But these changes should be the exception.