Scope

Estimating your pro­ject

Estimations should al­ways be con­sid­ered as just that - es­ti­ma­tions. Anyone with ex­pe­ri­ence build­ing soft­ware knows that the un­ex­pected of­ten oc­curs dur­ing de­vel­op­ment and should al­ways be planned for, in or­der to man­age ex­pec­ta­tions. The best plan is to take a sci­en­tific ap­proach that has al­lowances for the key fac­tors that of­ten im­pact a pro­jec­t’s time­line. These fac­tors in­clude al­lowances for risk, man­ag­ing tech­ni­cal debt, al­low­ing time for reg­u­lar busi­ness op­er­a­tions and pro­vid­ing time for pro­ject-re­lated work that is­n’t de­vel­op­ment (for ex­am­ple plan­ning and re­view meet­ings).

Estimating Time

Estimating at its core can be man­aged in sev­eral ways, but it’s rec­om­mended to use a time-based sys­tem. A gen­eral rule of thumb when es­ti­mat­ing is that the big­ger and more com­plex some­thing is, the less pre­cise you can be. The time-based val­ues fol­low a Fibonacci-like se­quence. This is com­mon prac­tice within ag­ile es­ti­ma­tions to en­sure de­vel­op­ers don’t get too caught up in the specifics, and in­stead fo­cus on rel­a­tive scale ver­sus other work. Splitting the es­ti­ma­tions be­tween de­vel­op­ment and test­ing ef­fort can fur­ther sim­plify the process and al­low de­vel­op­ers to fo­cus on the spe­cific work item.

Risk Factor

The more com­plex and un­fa­mil­iar a story is, the higher the risk that the time for de­vel­op­ment will be un­der­es­ti­mated. To en­sure that the risk is ap­pro­pri­ately con­sid­ered in es­ti­ma­tions, these fac­tors should be con­sid­ered for each ticket to al­low time for the un­knowns. Developers es­ti­mat­ing should score these risks pa­ra­me­ters, to be in­cluded in all cal­cu­la­tions. The risk fac­tor is cal­cu­lated based on the un­fa­mil­iar­ity and com­plex­ity of the of the story.

Discovery Allowance

It is not un­com­mon for prod­uct fea­tures to change and even be­come more com­plex dur­ing nat­ural dis­cov­ery in the de­vel­op­ment phase. With that in mind, it is ad­vised to pro­vide an al­lowance for when the de­liv­ery team needs time to scope out new dis­cov­ery or de-risk a con­cept dur­ing de­vel­op­ment. The dis­cov­ery al­lowance is spent at the dis­cre­tion of the de­liv­ery team and prod­uct owner. It will be used when the in­tent of a fea­ture has changed, de­tails de­fined were in­suf­fi­cient or are deemed too high-risk.

Delivery Allowance

During the de­vel­op­ment process, teams are fo­cused on de­liv­er­ing high-qual­ity fea­tures at a de­fined pace. This al­lows the team to en­sure that fea­tures are de­liv­ered to the de­fined spec­i­fi­ca­tion. However, de­fects and po­ten­tial im­prove­ments out­side of these re­quire­ments are a re­al­ity of soft­ware de­vel­op­ment. Experience has shown that all pro­jects re­quire pe­ri­ods of time, known as Iteration N, to ad­dress these de­fects and im­prove­ments to pre­pare for pro­duc­tion. The length of time tends to di­rectly cor­re­late to the size of the pro­ject. Tasks per­formed dur­ing Iteration N tend to in­clude tack­ling de­fects, ad­dress­ing tech­ni­cal debt and im­ple­ment­ing core im­prove­ments. These all share a com­mon goal; im­prov­ing prod­uct and code qual­ity.

Also fac­tored into a de­liv­ery al­lowance should be time for re­leas­ing the soft­ware. The most time-con­sum­ing re­lease is to a pro­duc­tion en­vi­ron­ment. The pro­duc­tion en­vi­ron­ment is the ‘final’ live ver­sion of the ap­pli­ca­tion.

The Launch Iteration (period of time set aside to re­leas­ing) be­gins the mo­ment an ap­pli­ca­tion is ready to move to a pro­duc­tion en­vi­ron­ment. Generally, the first re­lease will be the longest and will grad­u­ally de­crease in time the more of­ten the ap­pli­ca­tion is re­leased. Typically, dur­ing the it­er­a­tion, the team should be fo­cused on re­solv­ing any out­stand­ing is­sues block­ing re­lease, doc­u­ment­ing the ap­pli­ca­tion, prepar­ing for the Support team and qual­ity as­sur­ance processes.

Allocation Factor

Within any com­mer­cial soft­ware op­er­a­tion, de­liv­ery teams can’t be al­lo­cated to their de­vel­op­ment work for all work­ing hours. Activities like in­ter­nal meet­ings, help­ing their peers and learn­ing & de­vel­op­ment take up time and should be recog­nised when es­ti­ma­tions are be­ing con­sid­ered. This time should be fac­tored into an al­lo­ca­tion fac­tor that can be ap­plied across all es­ti­ma­tions.

The al­lo­ca­tion fac­tor also ac­counts for time that is­n’t de­vel­op­ing fea­tures but is still pro­vid­ing value to the cus­tomer. All scrum re­lated meet­ings and time spent re­leas­ing to the beta en­vi­ron­ment form part of the al­lo­ca­tion fac­tor. It is ex­pected that any al­lo­ca­tion cal­cu­la­tions will be ap­prox­i­mate based on reg­u­lar busi­ness ac­tiv­i­ties, such as it­er­a­tion ca­dence and stan­dard monthly learn­ing and de­vel­op­ment al­lowances