How to Control Scope Creep in Agile

Project managers and others new to agile often ask me "how do you control scope creep in the Agile software development life cycle (SDLC)?"

From http://m.odul.us/

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.

So what is scope creep in Agile, and how do you control it?

• It would be scope creep if the stakeholders want to swap new work for work already completed.  If you have completed development and testing on a software feature, the project stakeholders don't get to say, "oh, whoopsie, the market has changed, and we don't need it any more--please go back and change it.  Instead of doing A, we now want to do B.  We're agile!  Yay!  It's not scope creep."  Wrong--it certainly is scope creep, if the team agrees to do it.  The team doesn't have a time machine, and the time to develop Feature A is already gone.  If the team needs to kill Feature A and swap in new Feature B instead, that is a new request which needs to be traded off against other requests that are still in the future for the team.
• It would be scope creep if the stakeholders want to swap something big for something small.  Let's go back to the Mars Curiosity Rover for example.  If the team is budgeted to do a drop-down with choices of pepperoni, mushrooms, and sweet corn, and suddenly you want them to develop the Mars Rover in the same time frame, and they agree to do so, that would be scope creep.

And how do you control it?  If you're an agile team, you point to your pile of completed work, your team's track record for delivering every two weeks, and your projected delivery date for the next production deployment.  You say, "We have committed to this plan, and we are delivering to it with fully production-ready code every two weeks.  If you add additional work, we will not be able to deliver on time.  Here is our evidence."  Notice that you're not having a conversation about who said what six months ago.  You are all squarely focused on the delivery date and the probable contents of the software to be delivered on that date.  You are all securely committed to keeping quality constant, rather than agreeing to allow more work to creep into the schedule.  That's the responsible conversation to be having, so that's really nice.

Can scope still creep?  Yes, certainly.  If you have unreasonable product owners, an agile project is vulnerable to scope creep.  But if you keep product ownership reasonableness constant, an agile project is actually much less vulnerable to scope creep than a waterfall project, simply because it is built to support the need for change.  Agile requirements are pointed towards "what the business will need at delivery time," where waterfall requirements inevitably point back towards "what the business thought it needed at project charter time."  An agile team will not nickel and dime its product owner to death, and an agile team will be able to provide really good evidence to show why a request will or will not work with a projected budget and time line.

In the end, scope creep is actually easier to control in Agile.  So to me the real question should be:  how do you control scope creep in waterfall?