This has been a good dialog. It has made me re-evaluate some aspects of the iteration that I took for granted.
When I hear changing iteration scope within the iteration, I think of a product owner who can't commit for even a small period of time (an iteration). Changing priorities frequently within an iteration can hurt the team's productivity as they're constantly re-evaluating what they're trying to accomplish. In these cases, it is generally better to push the new stories to the next iteration (in other words, I'd agree with Chris in that in my experience, it is rarely necessary to add mid-iteration). But, you need to do what makes sense for the particular situation.
As we've gone back and forth in this discussion, it sounds like Roger is focusing more on the scenario where a team runs into an unexpected issue during the iteration. In other words, it didn't work out as planned and you need to adjust. For example, a story is taking much longer (or shorter) than expected. Some times these will cancel each other out. Or worst case, you won't complete some of the stories and the remaining work gets captured as new stories in the next iteration (or later if you decide it is less important). My general guidance would be to always finish the iteration on time and split stories as necessary.
In other cases, you might determine that a story (or on a smaller scale an acceptance criteria) is much bigger than expected or less valuable than expected and might not be worth it. Or maybe that something is not ready (i.e., it will be much easier if you wait). In these cases, you need to do what makes sense. Don't do it just because you said you'd do it. Do it because that is what makes sense.
Obviously, if you finish an iteration's stories early, you don't just hang out, you see what else you can take on. Do what makes sense.
More thoughts
This has been a good dialog. It has made me re-evaluate some aspects of the iteration that I took for granted.
When I hear changing iteration scope within the iteration, I think of a product owner who can't commit for even a small period of time (an iteration). Changing priorities frequently within an iteration can hurt the team's productivity as they're constantly re-evaluating what they're trying to accomplish. In these cases, it is generally better to push the new stories to the next iteration (in other words, I'd agree with Chris in that in my experience, it is rarely necessary to add mid-iteration). But, you need to do what makes sense for the particular situation.
As we've gone back and forth in this discussion, it sounds like Roger is focusing more on the scenario where a team runs into an unexpected issue during the iteration. In other words, it didn't work out as planned and you need to adjust. For example, a story is taking much longer (or shorter) than expected. Some times these will cancel each other out. Or worst case, you won't complete some of the stories and the remaining work gets captured as new stories in the next iteration (or later if you decide it is less important). My general guidance would be to always finish the iteration on time and split stories as necessary.
In other cases, you might determine that a story (or on a smaller scale an acceptance criteria) is much bigger than expected or less valuable than expected and might not be worth it. Or maybe that something is not ready (i.e., it will be much easier if you wait). In these cases, you need to do what makes sense. Don't do it just because you said you'd do it. Do it because that is what makes sense.
Obviously, if you finish an iteration's stories early, you don't just hang out, you see what else you can take on. Do what makes sense.