SOFTWARE DEVELOPMENT

Using soft­ware es­ti­ma­tions to ac­count for scope dis­cov­ery

This ar­ti­cle brings to­gether two of our favourite dis­cus­sion points — soft­ware es­ti­ma­tions and scope man­age­ment.

The best way to il­lus­trate the value of ac­count­ing for scope dis­cov­ery is to tell you about my lat­est ex­pe­ri­ence build­ing Ikea fur­ni­ture. I bought a new TV cab­i­net af­ter what felt like hours walk­ing in cir­cles with the faint smell of meat­balls tempt­ing me. I got home and felt mo­ti­vated to put this cab­i­net to­gether im­me­di­ately. Ever the op­ti­mist, I gave my­self 90 min­utes to put it to­gether be­fore I had to leave. Some read­ers might be think­ing; that’s way too long to put to­gether a cab­i­net (unfortunately the ex­tent of my handy work skills is­n’t the sub­ject of this ar­ti­cle).

Once I un­packed the items I re­alised that I did­n’t ac­count for some­thing that would sig­nif­i­cantly im­pact my es­ti­mates. There was no con­sol­i­dated set of in­struc­tions. Each part of the cab­i­net had its own set of in­struc­tions but there was noth­ing telling me how to bring each part to­gether. Now, I was­n’t build­ing any­thing more than I ini­tially es­ti­mated for. There was no scope creep. I made a dis­cov­ery early on that had an im­pact on my es­ti­ma­tions.

Similarly, dis­cov­er­ies are made in soft­ware de­vel­op­ment that aren’t nec­es­sar­ily any­one’s fault. The prod­uct owner has­n’t al­lowed the scope to creep and the de­vel­op­ment com­pany has­n’t failed to de­liver the re­quire­ments. The bot­tom line is that it af­fects the de­liv­ery time, which im­pacts pro­ject costs and re­lease times.

We’ll use his­tor­i­cal data to de­ter­mine what the av­er­age amount of dis­cov­ery has been as well as how it can be ad­dressed dur­ing the es­ti­ma­tions stage.

How much dis­cov­ery can you ex­pect?

We ran the num­bers on some pre­vi­ously pro­jects to de­ter­mine what the level of dis­cov­ery we can ex­pect is.

On av­er­age we have seen a 15% in­crease in tick­ets as a re­sult of dis­cov­ery.

The in­for­ma­tion used for this sta­tis­tic looked at the num­ber of tick­ets that were com­pleted dur­ing the first mile­stone of past pro­jects. It was then con­trasted with the num­ber of tick­ets es­ti­mated, and the change re­quests were re­moved — giv­ing us our per­cent­age of dis­cov­ery tick­ets.

On av­er­age we have seen a 15% in­crease in the num­ber of tick­ets due to dis­cov­ery. This does­n’t nec­es­sar­ily equate to a 15% in­crease in time. That is de­ter­mined by the size of each of those tick­ets. What is cer­tain is that dis­cov­ery tick­ets will have an im­pact on the length of the pro­ject and it would be short sighted to sim­ply dis­miss them.

How can you han­dle dis­cov­ery tick­ets us­ing soft­ware es­ti­mates?

Step 1: Acknowledge

One of the worst mis­takes you can make is as­sum­ing every­thing will go ex­actly as ex­pected. Assuming that the ex­act back­log will be de­vel­oped within the ex­act es­ti­mates is a naïve ap­proach to take. It’s im­por­tant to ac­knowl­edge that there will be a de­gree of vari­a­tion and plan for it.

Step 2: Incorporate it into your es­ti­mates

Once it’s recog­nised, the next step is to plan ap­pro­pri­ately for it. We do this through the es­ti­ma­tions process. We’ve taken a sci­en­tific ap­proach to soft­ware es­ti­mates you can learn about here. We ap­ply a fac­tor of 10% to es­ti­mates in or­der to ac­count for dis­cov­ery. As pre­vi­ously men­tioned, the ticket growth of 15% does­n’t al­ways cor­re­late to an equiv­a­lent in­crease in time. We’ve found that the cor­re­la­tion be­tween dis­cov­ery tick­ets and time is some­where be­tween 0 and 1. You may find that yours is higher or lower de­pend­ing on your process.

Step 3: Refine

Chances are you won’t guess right the first time. The closer you track your dis­cov­ery tick­ets, the more ac­cu­rate you can be when you look at re­fin­ing that data. Our rec­om­men­da­tion is to cre­ate a dis­cov­ery is­sue type in the pro­ject man­age­ment soft­ware you use. Be vig­i­lant when mon­i­tor­ing and la­belling is­sue types.

Give me the sum­mary;

  • It’s im­por­tant to in­cor­po­rate dis­cov­ery in your es­ti­ma­tions.
  • Our analy­sis has found there is a 15% in­crease in tick­ets from dis­cov­ery.
  • Ticket in­crease does­n’t cor­re­late ex­actly with time.
  • We al­low for a 10% dis­cov­ery growth dur­ing the sci­en­tific es­ti­ma­tions process.
  • Measure and re­fine your process to de­ter­mine what that per­cent­age al­lowance should be for you.

ABOUT THE AUTHOR

Yianni Stergou

Marketing en­thu­si­ast and FIFA ex­tra­or­di­naire

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

How to Budget for an Agile Software Development Project

11 September 2019

What are the monthly op­er­a­tional ex­penses to bud­get for a soft­ware ap­pli­ca­tion pro­ject?

02 March 2020

The Process and Price of Software Releases

19 May 2020

Your vi­sion,

our ex­pe­ri­ence

Book an con­sul­ta­tion