The Effect of Scope Length on Development Length


Project scop­ing is a cru­cial part of our Way of Working. It is where we can in­ves­ti­gate the prob­lem state­ment and de­sign a so­lu­tion that will res­onate with the user base. The length it takes to scope soft­ware dif­fers based on its com­plex­ity and the size of the so­lu­tion. As a re­sult we rec­om­mend the scope length dur­ing ini­tial con­sul­ta­tions based on the de­tails of the pro­ject. There will be an ar­ti­cle that ad­dresses how we cal­cu­late that rec­om­men­da­tion in the fu­ture.

This ar­ti­cle fo­cuses on a dif­fer­ent ques­tion. Does the scop­ing length im­pact the pro­jec­t’s de­vel­op­ment length?

Lines of thought

We had two hy­pothe­ses re­gard­ing the im­pact that scope length would have on de­vel­op­ment. The first is that the length of time scop­ing is based on the com­plex­ity and size of the pro­ject there­fore de­vel­op­ment es­ti­ma­tions are likely to be larger.

The sec­ond hy­poth­e­sis is that more time scop­ing would give us the time to find bet­ter ways of de­vel­op­ing and im­ple­ment­ing the soft­ware. As a re­sult that would ac­tu­ally shorten de­vel­op­ment time.

Both of these are rea­son­able as­sump­tions. And in re­al­ity, they could both be cor­rect to a de­gree. But we wanted to know what has the big­ger im­pact.


During our in­ves­ti­ga­tions we set out to find the cor­re­la­tion be­tween;

  1. Scope length and de­vel­op­ment length,
  2. User sto­ries and de­vel­op­ment length, and,
  3. User sto­ries and scope length.

Analysing the data

To in­ves­ti­gate the cor­re­la­tion, we ag­gre­gated data from our past 8 pro­jects. These pro­jects var­ied in scop­ing length with 3x 2 week scopes, 3x 3 week scopes and 2x 4 week scopes. Our find­ings showed;

There is a 90% cor­re­la­tion be­tween scope time and de­vel­op­ment time.
There is a 75.7% cor­re­la­tion be­tween de­vel­op­ment length and user sto­ries.
There is a 57.8% cor­re­la­tion be­tween scope length and user sto­ries.

What does this mean?

The re­sults con­firm our ini­tial hy­poth­e­sis. The scop­ing length is pre­scribed based on the com­plex­ity and size of the pro­ject. This means we can ex­pect de­vel­op­ment time on pro­jects that re­quire longer scopes to be longer.

There is an­other pos­si­ble con­trib­u­tor to the cor­re­la­tion. With more time, there is the op­por­tu­nity to get more done. It is pos­si­ble that we are scop­ing more ‘nice to have’ fea­tures be­cause time per­mits. In a shorter scope these fea­tures may be de-pri­ori­tised un­til a later scope.

In a per­fect world with no com­mer­cial re­stric­tions we would run an ex­per­i­ment where the same pro­ject is scoped by mul­ti­ple teams for vary­ing lengths. This would al­low us to prove or dis­prove our sec­ond hy­poth­e­sis.

Are there any neg­a­tives to scop­ing too long?

The short an­swer to this ques­tion is yes. If we have said that the scop­ing length im­pacts de­vel­op­ment time then we can as­sume that by scop­ing longer we are build­ing for longer. At some point in time we are scop­ing func­tion­al­ity that may not be built for an­other 4-6 months. This is plenty of time for a mar­ket to change its be­hav­iour or to learn from pri­ori­tised func­tion­al­ity.

One of our oblig­a­tions as ad­vi­sors is to help find the right scop­ing length and de­vel­op­ment length. Regardless of the scop­ing length, we pro­vide rec­om­men­da­tions at the end of scope to help de­liver a prod­uct within the bud­get. This comes back to the ap­proach of start­ing with prob­lem state­ment when de­vel­op­ing soft­ware.

Discover Software


Yianni Stergou

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