Great post!

Good point. I think one of the best ways to insure that the scope doesn’t change on a backlog items it to make sure the backlog item is vague in terms of implementation, and very specific in terms of the problem which needs to be solved.

I think the biggest challenge is balancing the inherently vague requirements available at the time the team takes a backlog item with the need to avoid having the story morph into something other than what the team agreed to take. The team and product owner need to come to a concensus regarding when a backlog item has gotten “too big” or has changed “too much” to be considered the same thing the team agreed to in planning.

The team needs to be mindful of the possibility that “being open and flexible regarding requirements” can mean “the product owner didn’t get the backlog item properly described and the story properly written before asking the team to take on the work”. As new requirements become known during the sprint, a thoughtful discussion needs to occur between the product owner and the team to prevent this kind of scope creep.