Raising the Quality of Your Software Project: When to Trim the Tail

It’s dif­fi­cult to ex­plain the con­cept of bugs in soft­ware with­out go­ing through the de­vel­op­ment cy­cle first hand. One of the bet­ter ways to think about it is through the lens of test­ing. During the plan­ning and de­sign phase of a pro­ject there is an an­tic­i­pated user flow. The soft­ware ap­pli­ca­tion is de­signed to lead users through that flow. As a re­sult, that is the way it is tested. Unfortunately users don’t al­ways in­ter­act with an ap­pli­ca­tion the way we orig­i­nally en­vis­aged. For ex­am­ple they might re­turn to the home screen when we ex­pect them to sub­mit a pay­ment.

Because it’s im­pos­si­ble to know every vari­a­tion of how a user will in­ter­act with the ap­pli­ca­tion, there will al­ways be bugs. Bugs also oc­cur when third party frame­works (eg. Chrome, iOS, Android) are up­dated, so what used to work as ex­pected, no longer does. Don’t worry, there are mea­sures that can be taken to re­duce the num­ber of bugs and raise the qual­ity of the soft­ware. WorkingMouse does this through a process called trim the tail.

Trim the Tail

The trim the tail al­lowance is used to add a chunk of time into the pro­ject to ac­count for any bugs or mi­nor im­prove­ments which may pop up. Experience has shown us that every pro­ject re­quires pe­ri­ods of clean­ing up time where the team needs time to pause on ac­tive de­vel­op­ment and in­stead fo­cus on the work they have al­ready done. The ir­re­sistible urge is to block out 6 weeks of de­vel­op­ment time and spend the en­tire time de­vel­op­ing new fea­tures. So what hap­pens next?

Case Study: What hap­pens when there’s no Trim the Tail?

Before the Way of Working was cre­ated, there were pro­jects that did not al­lo­cate a pe­riod of time to qual­ity im­prove­ments. One par­tic­u­lar pro­ject had orig­i­nally planned to spend the last few days of de­vel­op­ment on bug fixes and rais­ing the qual­ity. However due to de­layed user ac­cep­tance test­ing, change re­quests were thrown into the trim the tail (Iteration N) pe­riod. Quality im­prove­ments were pri­ori­tised be­low new changes. This had reper­cus­sions when the ap­pli­ca­tion was re­leased into a pro­duc­tion en­vi­ron­ment. These weren’t detri­men­tal to the per­for­mance of the soft­ware but it did dam­age the user ex­pe­ri­ence. Consequently it was the sup­port mech­a­nism of WorkingMouse - Rogue Two that had to save the day’.


Implemented within the Codebots Way of Working is a trim the tail fac­tor. The trim the tail fac­tor cal­cu­lates a pe­riod of time which can be used through­out the pro­jec­t’s time­line. This cre­ates a bank of time which can be drawn from at any point in the pro­jec­t’s time­line. When the team lead and the cus­tomer agree it is re­quired, the stan­dard de­vel­op­ment progress can be paused, and the team can en­ter into an Iteration N. The length of this it­er­a­tion can vary de­pend­ing upon the amount of work which is re­quired. This pe­riod of time is then taken from the bank and the run­ning tally is up­dated.

Through these learn­ings we de­fined a rec­om­mended fac­tor that should be ap­plied to every soft­ware pro­ject. Currently, the trim the tail fac­tor is cal­cu­lated as a 1.25* mul­ti­plier on the time es­ti­mate (including risk and al­lo­ca­tion fac­tor).


Case Study: Using Trim the Tail to your ad­van­tage

Tool Protect is an ap­pli­ca­tion de­signed to help tradies keep their tools safe. The App was turned around in un­der 5 weeks which does­n’t leave much time for ex­ten­sive test­ing. With the Trim the Tail fac­tor ap­plied at the end of the pro­ject, it was suc­cess­fully com­pleted and ca­pa­ble of ac­com­mo­dat­ing a large in­flux of users (after re­ceiv­ing a fea­ture story on Channel 7 News). Since then the ap­pli­ca­tion has also launched in New Zealand. It is cur­rently man­aged and sup­ported by Rogue Two.

As men­tioned ear­lier, the fac­tor cal­cu­lates a pe­riod of time. This time can be taken at any stage dur­ing the de­vel­op­ment pe­riod. The rea­son it is called trim the tail is be­cause we want to move away from one big al­lot­ment of time at the end of the pro­ject.

Case Study: Don’t wait un­til the end

One of the most com­mon mis­takes is to wait un­til the very end of a pro­ject to con­duct all qual­ity im­prove­ments. For small pro­jects/​min­i­mum vi­able prod­ucts, this may be ac­cept­able. However, the longer a pro­ject is an­tic­i­pated to take, the more bugs/​de­fects that might arise. A pro­ject that was com­pleted be­fore the Way of Working waited over 12 weeks be­fore des­ig­nat­ing time to qual­ity im­prove­ments. This left a large back­log of bug fixes that im­pacted on the teams pro­duc­tiv­ity dur­ing fea­ture de­vel­op­ment it­er­a­tions. The learn­ings that came from the pro­ject sug­gested that it­er­a­tion n (dedicated to qual­ity im­prove­ments) need to be taken in­cre­men­tally dur­ing a pro­ject.

To sum­marise, there is no sil­ver bul­let for bug-free soft­ware. But there are meth­ods and tac­tics that can be used to raise the qual­ity. Use the fac­tor of 25% as a start­ing point. Every 4-5 weeks of fea­ture de­vel­op­ment may re­quire one week of it­er­a­tion n. Trim the tail so the prob­lems don’t pile up at the end.


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.

Your vi­sion,

our ex­per­tise

Book an con­sul­ta­tion