Scope creep, for those of you reading this blog purely for the joy of it, is when a team has agreed to build a piece of software for a given price in a given time frame, and then the person who wants the software changes their mind about what they want, and they ask the team to do something outside the initial agreement, often without concomitant adjustments to the budget or the time frame. Scope creep is nasty, and left unchecked may cause blindness or death. Or at least loss of sleep for the team members, or perhaps loss of hygiene if they opt to skip showers in order to fit in a nap.
And yet business needs change. Nobody buys VT-100 terminals these days, and only audio aficionados buy vacuum tube stereos. The iPhone 4 gives way to the iPhone 4S (but still doesn't provide turn-by-turn spoken navigation). If you're the person buying the software, you don't want to contract for a VT-100, and then have to take delivery on it ten years later when everyone has moved on to a VT-220.
In the "waterfall" methodology, you control scope creep through a thing called "Change Control" where everyone agrees that the original contract was written in blood. Although you as a product owner can negotiate with the team for changes in the plan, to stay abreast of the market, it will cost you. At the end of your painful and protracted negotiations, you will indeed get something different than what you requested plus some interesting new bruises. But your bruises help to console the team and get them through the night on the Sunday of Memorial Day when they are doing the production deployment and you are out on your boat with vodka tonics and attractive companions of one or more genders in brightly colored swimwear.
In agile, we reserve the right to bruise you, but we have a slightly different perspective. For one thing, we purposely structure the work so that many things that might have been scope creep under a waterfall SDLC aren't a problem. Here are some agile rules of engagement:
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.