Development

De-risking soft­ware

As dis­cussed within Estimations, an al­lowance should be avail­able for de­vel­op­ers to de-risk cer­tain fea­tures dur­ing de­vel­op­ment. The first step when us­ing this al­lowance is to iden­tify fea­tures that are too high-risk for de­vel­op­ment and there­fore should fail your Definition of Ready. Once these have been iden­ti­fied, a tech spike could be used to time-box and ex­plore the com­plex­ity and/​or un­fa­mil­iar­ity around a spe­cific fea­ture. The fo­cus of a tech spike should not be about de­liv­er­ing a work fea­ture, but in­stead achiev­ing a set of learn­ing ob­jec­tives.

There are gen­er­ally two ways to al­low time for tech spikes:

• Within Iteration: Simply put, the de­liv­ery team should treat the time-boxed tech spike like any other ticket and in­clude it within their it­er­a­tion’s es­ti­ma­tions. This means that within the time-boxed it­er­a­tion, there should be time al­lo­cated for one or more de­vel­op­ers to de-risk this fea­ture.

• External to Iteration: For higher pri­or­ity de-risk­ing ex­er­cises, it is pos­si­ble to pause the fol­low­ing it­er­a­tion in favour of in­ves­ti­gat­ing the fea­ture. This re­sults in the en­tire team fo­cus­ing on the fea­ture, which should re­sult in a faster res­o­lu­tion, but at the cost of start­ing the next it­er­a­tion.