Managing Scope Creep with the Variation Metric


How does scope creep oc­cur?

To im­ple­ment the vari­a­tion met­ric as a so­lu­tion, it is im­por­tant to first un­der­stand how 44% of busi­nesses in 2015 ex­pe­ri­enced scope creep’. The first part of the an­swer is that the like­li­hood a pro­ject will ex­pe­ri­ence scope creep is very high. Largely, this is due to the num­ber of ways in which it can in­fil­trate a pro­ject. One ex­am­ple is if a cus­tomer has mo­ments of clar­ity or epipha­nies that re­sult in even mi­nor changes to the cur­rent sprint (minor changes can add up to a sig­nif­i­cant im­pact). Another is when the lack of de­tails from the stake­hold­ers are only iden­ti­fied af­ter more care­ful thought about what it re­ally en­tails to com­plete a sprint. These are the two ma­jor en­try points of scope creep that a pro­ject man­ager should be aware of.

The sec­ond part of the an­swer is that there can be in­ef­fec­tive man­age­ment of scope creep when it does oc­cur. Generally busi­nesses build a pro­ject from a prod­uct back­log filled with re­quire­ments. These re­quire­ments are pri­ori­tised and the ones that help cre­ate the most ba­sic func­tion­al­ity of an app form the first sprint. The other fea­tures are grouped into sub­se­quent sprints ac­cord­ing to their pri­or­ity. This strat­egy is im­por­tant to the ag­ile method­ol­ogy be­cause it al­lows a busi­ness to re­plan and op­ti­mise later re­leases at the ear­li­est point pos­si­ble, in or­der to cre­ate the best prod­uct/​mar­ket fit. Building ag­ile re­duces the chance of un­nec­es­sary ex­pen­di­ture as well as the risk that a de­vel­oper will spend un­nec­es­sary time on build­ing re­quire­ments that would even­tu­ally need to be adapted to work with changes to the ba­sic fea­tures.


However, some busi­nesses al­low cus­tomers to swap re­quire­ments dur­ing a sprint of the de­vel­op­ment process. On the sur­face this may seem like a good idea but in prac­tice it can be dif­fi­cult to do. The is­sue is that the swap can af­fect the de­pen­dency re­la­tion­ship be­tween the dif­fer­ent re­quire­ments in the sprint. The di­a­gram be­low shows how re­mov­ing one re­quire­ment can im­pact on the re­la­tion­ship be­tween the oth­ers and there­fore the over­all func­tion­al­ity of the app. These kinds of changes can lengthen the time of a sprint to a de­gree that negates the ef­fec­tive­ness of work­ing with ag­ile method­ol­ogy.


Introducing the Variation Metric

At WorkingMouse our so­lu­tion is to use a vari­a­tion met­ric and ap­ply par­tic­u­lar scope man­age­ment tech­niques de­pend­ing on where each part­ner (customer) is rank­ing. The vari­a­tion met­ric helps us mea­sure how much the re­quire­ments change dur­ing a sprint when com­pared with the orig­i­nal scope. You can see how this works in the im­age be­low. Say there is a pro­ject with 20 is­sues and the part­ner wishes to change one of these. The change would amount to a 5% vari­a­tion. However if the part­ner wanted to add an is­sue as well there would be a to­tal of 21 is­sues, with 2 changes and a 9% vari­a­tion.


Adding up the over­all vari­a­tion al­lows us to rank the part­ner at dif­fer­ent lev­els of scope creep. Depending where the part­ner ranks, you can ap­ply par­tic­u­lar man­age­ment strate­gies. For ex­am­ple a part­ner might be flagged as hav­ing reached warn­ing level (0-5%). This alerts you to re­view the pro­ject and iden­tify how the scope creep has oc­curred. Upon in­ves­ti­gat­ing, you may iden­tify the cause as be­ing a mis­com­mu­ni­ca­tion be­tween your busi­ness and the part­ner re­gard­ing the de­tails of some func­tion­al­ity. As a re­sult you can man­age this com­mu­ni­ca­tion fail­ure by re­view­ing knowl­edge trans­fer ses­sions and en­sure that the func­tion­al­ity is ad­e­quately rep­re­sented in the re­quire­ments back­log, UX flow and schematic di­a­gram.

If the vari­a­tion met­ric climbs fur­ther, this might flag that the com­mu­ni­ca­tion is­sue runs deeper. Upon ex­am­i­na­tion it is likely you will find that your part­ner’s vi­sion con­tin­ues to evolve past the MVP (min­i­mum vi­able prod­uct). While it is great for them to have fu­ture as­pi­ra­tions for the prod­uct, the scope is the MVP and not the life­time of the en­tire pro­ject. It is for the ben­e­fit of both par­ties to stick to the build, mea­sure, learn ethos. Therefore to man­age this kind of scope creep you should re­view how you are man­ag­ing your part­ner’s ex­pec­ta­tions.


The dif­fer­ence be­tween our strat­egy and oth­ers is we have a limit on scope creep. If the vari­a­tion met­ric ex­ceeds a thresh­old then a sprint fail has oc­curred. This means too many changes have been made for the sprint to be worth­while con­tin­u­ing. The ap­proach at WorkingMouse is to not let scope creep pass our man­age­able thresh­old. If it does then it is in the in­ter­est of all stake­hold­ers to halt the build un­til we find a so­lu­tion.


While our man­age­ment strat­egy is not the only so­lu­tion, it is im­por­tant for all busi­nesses to con­sider how they will deal with scope creep. All soft­ware de­vel­op­ers will at some stage ex­pe­ri­ence scope creep in their pro­jects. The key to a suc­cess­ful build is in how your busi­ness iden­ti­fies these risks and im­ple­ments man­age­ment strate­gies.

From a man­age­ment per­spec­tive, by iden­ti­fy­ing scope creep as it hap­pens, in real-time, you gain the op­por­tu­nity to man­age the ex­pec­ta­tions of all stake­hold­ers. And if the vari­a­tion is out­side of what man­age­ment con­sid­ers tol­er­ance, ac­tions can be taken by ei­ther re­vis­it­ing the price or the al­lo­cated re­sources.

Discover Software


Eban Escott

Big pic­ture thinker and Star Wars fa­natic

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion