Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 SETUP and DELIVER  SETUP and DELIVER   Scope Creep   Scope Creep

Lifecycle   »   Scope Management   »   Scope

You will often hear that scope is not important on an agile project, that you can change your mind on a whim and dart off into a different area of the business when the mood takes you. You will also hear that scope on an agile project is the same as scope on a waterfall project. Neither of these statements is correct. They are agile project myths that we will expand upon later in the Toolkit. For now, let us explain our use of scope and immediately apologise for the level of detail we offer for what is ostensibly a really very straightforward, and at the same time misunderstood, concept.

During a project, we consider and monitor the scope of the project. First it is important that we look at the word: scope.

The word has a series of descriptions and meanings. These are, in carefully alphabetic order, the words amplitude, area, breadth, capacity, comprehensiveness, confines, dimension, expanse, extensiveness, extent, field, field of reference, latitude, magnitude, opportunity, range, reach, scale, size, space, span, sphere, spread, stretch, sweep, wideness. You will see that all these terms apply to our use of the word scope inside project development. They are terms we would use to demonstrate scope. Let us look at why we define and use it.

We identify and validate the scope of our project to ensure we are delivering something inside the business or technical area we intended but also to ensure we do not encroach on those business or technical areas outside our remit. So Let us look at how we use the term.

Throughout the project we use the term scope in two distinct, yet naturally related, ways. We define the scope of the work we perform but also the scope of the products we deliver. The work that we perform to deliver a product or outcome has a scope or breadth and we seek to ensure we retain the focus of our efforts within that sphere. The product or outcome we generate has individual features and functions that characterize it from another product or outcome. This then can be said to be another form of scope in terms of the range or capacity of the solution. So we have two scope terms to describe the reach or range of effort to deliver solutions that have a recognisable definable dimension.

The semantics are one thing and the work to define and confirm scope could warrant much deeper explanation. But it is really best to just jump in and see what pragmatic effort can be performed to achieve this. First we will define our scope then agree a way to monitor scope issues and inform the team of scope changes or other scope issues. Finally we will confirm that our project scope coverage is thorough.

We substantiate this by confirming we reviewed all relevant background materials including high level requirements with the customer representatives and can define scope in terms of phases performed, resources used, outcomes delivered, systems or functionality replaced, organisational areas affected as well as organisational boundaries that identify or constrain our involvement. This will undoubtedly involve a statement about the areas of the business not in scope for the proposed project.

On an agile project we welcome change. However there has to be a limit or some control over the scope of a piece of work otherwise ambiguity, confusion, disharmony and dispute is the ultimate and unfortunate natural path. This control is important in the area of scope management and an increase to scope in one area demands an equal and instant reduction of scope in another. It makes sense so whenever there is an instance of Scope Creep, we enact Scope Seep.


 SETUP and DELIVER     SETUP and DELIVER   Scope Creep    Scope Creep

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 201  Page: 214/444  Progress: 48.2%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.