What is scope creep and how to man­age it


Creating an app or web­site is an enor­mously ex­cit­ing process. It’s nor­mal for there to be func­tional and de­sign re­quire­ments, and it’s also nor­mal for those re­quire­ments to change. However, when the re­quire­ments of a pro­ject con­tin­u­ously in­crease with­out doc­u­men­ta­tion, risk man­age­ment or dis­cus­sion, a pro­ject will be­come dif­fi­cult to man­age. This sit­u­a­tion is called, ‘scope creep’. Scope creep is­n’t lim­ited just to soft­ware de­vel­op­ment, but re­gard­less of the fi­nal prod­uct, scope creep can be a night­mare for all in­volved and even cause the prod­uct to fail.

When a pro­jec­t’s re­quire­ments grow unchecked, this in­creases the de­vel­op­ment time. In turn, this in­creases the cost of im­ple­men­ta­tion and mud­dies the wa­ters of what is to be de­liv­ered and why. Put sim­ply: too many fea­ture re­quests can de­rail a pro­ject.

Why does it hap­pen

During de­vel­op­ment of a soft­ware ap­pli­ca­tion, prod­uct own­ers and other stake­hold­ers can of­ten get very en­thu­si­as­tic about the power of the sys­tem be­ing made. This can lead to var­i­ous ideas or ad­di­tions to the prod­uct. Another way this can hap­pen is when nec­es­sary fea­tures were missed dur­ing scope or not re­alised un­til de­vel­op­ment starts.

Product de­sign­ers and pro­ject man­agers nat­u­rally want to en­sure that prod­uct own­ers are happy with the out­come of de­vel­op­ment, so the first im­pulse to these change re­quests is to sim­ply ac­cept them and add them onto the ex­ist­ing stack of work. This is a mis­take, re­gard­less of how big the ticket is, be­cause any change to the im­ple­men­ta­tion will af­fect the back­log, time, cost and fi­nal de­liv­er­able. The habit of al­low­ing change re­quests to slide in unchecked will even­tu­ally lead to scope creep and, even­tu­ally, a pro­ject in need of res­cue.

3 ways to avoid scope creep

Nominate a prod­uct owner

It’s nor­mal for prod­ucts to have mul­ti­ple stake­hold­ers in­volved in the scop­ing and de­vel­op­ment process, and be­cause they are hu­man be­ings, they’ll have opin­ions and at­ti­tudes which are uniquely theirs. Whilst every­one is en­ti­tled to their opin­ions, it’s im­por­tant to nom­i­nate a prod­uct owner for the pur­poses of the pro­ject who gets to make the call on what fea­tures stay in and what fea­tures will have to wait. This also helps the prod­uct de­sign­ers and squad leads be­cause it makes com­mu­ni­ca­tion faster and eas­ier.

Continuously re­view the back­log and track changes

Any changes which are made to the pro­ject should be logged and tracked in the back­log. The back­log is the or­dered list of every­thing that is needed in a given prod­uct, and is the source of truth for the de­vel­op­ers and de­sign­ers. If it is­n’t doc­u­mented in the back­log, then it will not be built. At WorkingMouse, we pro­vide an es­ti­mate against this back­log be­fore de­vel­op­ment starts so prod­uct own­ers can get a sci­en­tific break­down of the time and costs to cre­ate an ap­pli­ca­tion. Feature re­quests or changes mean that the back­log needs to be up­dated, with the cir­cum­stances of the up­date recorded. In turn, this also changes the time and cost es­ti­mate.

Provide an es­ti­mate for changes

Depending of the scale of the change re­quest, a Squad Lead is able to pro­vide a prod­uct owner a few op­tions for de­vel­op­ment. The first is to ex­tend de­vel­op­ment time to al­low for the im­ple­men­ta­tion of the new ticket. The sec­ond is to swap the new ticket with an old one, es­sen­tially just re-al­lo­cat­ing ex­ist­ing re­sources. The third op­tion is to de­lay the de­vel­op­ment of the new fea­ture un­til a later build, re­serv­ing it for a fu­ture scope.

This may be a tough de­ci­sion and will de­pend on the pro­jec­t’s bud­get, dead­line and, of course, any tech­ni­cal hur­dles the de­vel­op­ers and de­sign­ers may have to over­come in or­der to make the fea­ture a re­al­ity. A good squad lead will con­fer with their team and pro­vide an hon­est ex­pla­na­tion of the op­tions and their con­se­quences be­fore de­vel­op­ment of that fea­ture starts.

Scope creep can sneak up on pro­ject man­agers and prod­uct own­ers alike, and once it starts, it can be dif­fi­cult to steer a pro­ject back on track. The best way to deal with scope creep is to pre­vent it from hap­pen­ing in the first place, by be­ing aware of the signs, keep­ing a pro­ject sched­ule and en­sur­ing that the back­log is prop­erly main­tained through­out de­vel­op­ment.

Discover Software


Rhiannon Stevens

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

Your vi­sion,

our ex­per­tise