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

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

Comments

  1. 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.

    ReplyDelete
  2. 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: http://www.slideshare.net/adidierk/software-scope-creep-and-the-golden-ratio-a-limit-to-effective-agility

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica