Sunday, January 18, 2009

Running Scope creep backwards

One of the criticisms levied at Agile software development is that of Scope Creep. Project managers seem particularly sensitive to this issue, probably because its been fatal to many projects before and thus Project Manager are trained to watch for it and come down hard on it.

However, I’ve come to the conclusion that in a lot of Agile work the secret is to run Scope Creep backwards. Rather than have a project get bigger as more and more requests are added to it what we need to do is have it get smaller over time. Let me explain.

Typically a product/project gets specified and then work proceeds, as it does more and more "change requests" appear, things people hadn't thought of, ideas for what else it could do - scope creep. (See my piece, Why do requirements change from a few years ago if you want to know more about the why.)

As projects grow in size the chances of them meeting any deadline diminish. This is why traditional Project Managers look at Agile and throw their hands up in the air seeing rampant Scope Creep.

But if you run it backwards, write the spec, write it as big as you like, who cares how big you write it or how many features you put in. The bigger it is the less people will remember. (See my piece on the Documentation myth for why big documents don’t work.)

Allowing everything into the spec means you don’t have to have those hard conversations about what’s in and what’s out. Everyone gets to feel there thing is in.

Now prioritise. If its really big make a first pass with MoSCoW rules. Anything which isn't MUST have can be ignored for now - you've probably got more must's than you have time for anyway. Generally I’m not a fan of Moscow rules but they are OK as a starting point when you have a lot of requests.

(Note: that’s MoSCoW rules, not Moscow rules - personally my only Moscow rule is avoid the city, my last trip there was awful so future visits are restricted to changing planes.)

Now within the MUSTs prioritise 1, 2, 3.... N. No duplicate priotities. This way when something increases in priority ther things fall automatically, people immediately see the consequences of their decisions.

What criteria you use for prioritisation is up to you. Doing it by value makes a lot of sense, so does doing it by risk. It also makes sense to get some early wins under your belt.

Next work through the items in priority order.

Anything that comes in later (Scope Creep) has to be slotted into these priorities. Add a new item with priority 3 and everything 4..N moves down one.

Notice I’m not interested in change control. I don’t make any effort to restrict the work that is asked for. All I do is demand it is prioritised along with everything else. Valuable ideas can arrive at any point in the work so why draw an arbitary line to differenciate what was “in scope” and what was “out of scope.” The objective is deliver value.

Now as you work through the list you will find that with items 1..N' you have a a valuable product. Something you can at least show to customers, something people might even pay money for today.

Once you start getting real feedback - especially the sort represented by money - everything changes. Once you know what real customers want you are, literally, in business. You’ll want to add new items and look again at your priorities.

At this point you've saved yourself the work N'..N plus all the Should Have's, Could Haves, etc. This is running Scope Creep backwards.

What all of this highlights is that building a software product isn’t a binary decision. It isn’t “all of this stuff” or nothing. Its an analogue thing not a digital thing. Traditional projects spend a lot of time trying to prevent scope creep through tough change control procedures but really it doesn’t matter when a request comes in. What is important is what is the value it will bring.

Value, not arbitary dates, should be the criteria for deciding what to build.


  1. I see the same thing with respect to the must have's.

    If you imagine a story as a picture of a person set in a field, with mountains in the background (bear with me).

    In the beginning everybody wants the person's face to be detailed down to every wrinkle, the field to show each individual flower and the mountains to have snow and goats on them.

    As the agile project gets under way and the constraints kick in the story get's scoped down. This means in version 1 the person has an outline of hair, details eyes, nose outline, details mouth and no ears. The fields have 2 types of flowers, one drawn only a a circle on a stick, the other immaculately detailed. The mountains are just an outline.

    This means version 1 is still definitely recognisable as a person in a field - although only of interest to the people closest to the person in the picture.

    Then in version 1.5, 2, 2.5 the things that were lacking get drawn in and eventually (hopefully) everyone want to look at the picture.

    actually that might be a bit of a crazy metaphor, but it helps me think about how to scope things down. For instance, often there is a tradeoff to be made between having 5 features of a face as outlines, or having 2 as outlines, 2 as detailed painting and one completely left out.

  2. I recently have accepted a position with a company who practices Lean. If I hear "Scope Creep" one more time I will shoot myself. It comes out of their mouths like old tape loops. The bottom line is that once you start declaring scope creep, you squelch ideas. People are concerned they might be tagged the bad guy when the project or in this case, the Kaizen fails. Most devistating cost or time issues don't result from scope creep...they result from ineffective Project and Lean Leaders.


Note: only a member of this blog may post a comment.