Skip to main content

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)?"

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 scopeIf 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?


  1. interesting blog. It would be great if you can provide more details about it. Thanks you

    Agile Project Management

  2. I think you've such a thing called product backlog. So, if your product owner is coming up with new features to be added, or change the existing ones in the same time-box(iteration),I'd rather not allow it as a scrum master. But I'd certainly be happy to add those new requests to the product backlog and advise Product owner, to wait.

  3. Great article. I have recently published an online article that looks deeper into the Math behind controlling scope creep in agile projects. It proves several ideas you have in your post:


Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …