Vision = re­al­ity


With the pro­ject suc­cess­fully pre­pared, de­vel­op­ment can be­gin. The pur­pose of the de­vel­op­ment phase is to build soft­ware that meets the scoped re­quire­ments, in a man­ner that de­liv­ers value early and of­ten to the cus­tomer. The de­vel­op­ment of a prod­uct can com­mence at any point af­ter the scope has been fully de­liv­ered.

The cy­cle is com­prised of many it­er­a­tions which con­tinue un­til de­vel­op­ment has been com­pleted to the prod­uct own­er’s sat­is­fac­tion. Every it­er­a­tion in­cludes meet­ings, check­points and soft­ware re­leases to en­sure the de­liv­ery of func­tional soft­ware and keep the cus­tomer sat­is­fied.

The de­vel­op­ment work­flow is un­der­pinned by many prod­uct it­er­a­tions that re­sult in a re­leasable prod­uct ver­sion, typ­i­cally called a build. An it­er­a­tion is a short, time-boxed pe­riod when a de­liv­ery team works to com­plete a de­fined set of re­quire­ments. Iterations gen­er­ally have pro­ject re­lated goals as­so­ci­ated with them, but in gen­eral should de­liver an in­cre­ment that can be used and tested. Defining the work to be com­pleted dur­ing an it­er­a­tion, called the it­er­a­tion back­log, is a shared re­spon­si­bil­ity be­tween the prod­uct owner and the de­liv­ery team.

The length of de­vel­op­ment varies be­tween pro­jects and de­pends heav­ily upon the scale and com­plex­ity of the so­lu­tion. As men­tioned, there is a pref­er­ence to­ward shorter scopes, which tend to cre­ate smaller and more man­age­able de­vel­op­ment cy­cles. Reducing the size of a build not only al­lows for in­creased cer­tainty around es­ti­ma­tions, but also lets the Product team in­cor­po­rate user feed­back into sub­se­quent scopes.

Development infographic

Discover Software

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