To me, scope is a word from the bad old days of project management. A thing that was defined in painful detail and then cast in concrete, only ever to modified with huge expense and a pneumatic hammer.

How incredible then that we still believe it is ok to fix scope, that scope is something we expect people to specify at the start of a development chapter even though none of the players knows the full truth about what is being embarked upon.

Of course scope can be different things to different people and in the agile world perhaps scope means the realm of the effort we are collaborating on, in which case it most definitely is not rigid.

But lets just reflect on what it probably still means to the majority of developers who work for an old school project manager or perhaps a modern project manager working under old school constraints.

• We discuss the requirement with the client
• We specify the scope up-front and document it
• We get our client to sign off and agree to the scope
• We commence development of the scope
• We test and assure the functionality fits the scope
• We hand over the functionality for acceptance
• The client (perhaps reluctantly) accepts the functionality

Imagine if this process took 12 months and imagine if the client was working in an organisation that did not stand still for 12 months. What are the chances of the requirement being constant in that time? What are the chances of the scope being precisely the same? What are the chances of the client being happy with what was delivered a year later?

Scope doesn’t just increase - it can decrease. Functionality that cost $50K might no longer be needed 6 months down the line so why build it? We could all finish early and do something that the organisation actually needs with the money. Imagine that.

If it sounds good then check the blog roll on the right and/or some posts I’ve made on agile