How to Control Scope Creep in Agile

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:
 

• It's not scope creep if you're changing something before the team has started to think about the details.  In an Agile SDLC, we lay out the planned work at a high level before we start, to make sure we're in general agreement about how much the team will get done, but once the general size of the effort is agreed, details are purposely left to be determined later.  At the "planning game" stage of the project, we might specify that we need a user interface with about 10 fields.  But we don't specify what the exact fields are, what the validations on the fields will be, nor where they will park in the database, until we are ready to do actual development on that story.  Why do we wait?  To avoid scope creep even coming into the conversation!  This method allows you to change your mind without penalty, and to give you and your company a competitive advantage over product owners in other companies who are kept to their original contracted scope. If you are working with an agile team, all you've invested initially in that segment of your end product is a maximum of about 100 words on an index card.  If the team hasn't even done detailed analysis of the story, it's really no big problem to swap in a different 100 words.
• It's not scope creep if it doesn't create additional work for anyone.  So, you might say, there's a big difference between 100 words that say "Build a drop down field to allow someone to order pepperoni on their pizza, etc., etc.," and 100 words that say "Build the Curiosity Mars Rover, etc., etc."  That's right.  So in Agile, we will let you swap one story for another without penalty, but only if the team can estimate that the new story is roughly the same amount of effort as the old one.
• It's not scope creep if it's within the team's defined contingency allowance for "unknown unknowns."  Empirically, experienced agile delivery teams will tell you, new necessary scope will be discovered as you go.  When you put together your release plan, leave a 20% contingency completely open for this newly discovered scope.  You should still be careful not to introduce anything that isn't strictly needed, but if you discover as you go that to get what you need, you need some additional effort, you're still fine until you use up your contingency.
• Fundamentally, it's not scope creep if the delivered product is exactly what project stakeholders need at release time, and the code quality is such that you can continue to keep the software matched to the business needs indefinitely.  So long as the software development team and the people watching the market are in touch with each other and doing their jobs correctly with attention to intrinsic and extrinsic code quality, and so long as the team is able to work at a sustainable pace, the issue of "what did I say I wanted six months ago" is pretty much the least of your worries.  The important thing is that the software meets current business needs and will continue to do so.