Ite­ra­ti­ve soft­ware deve­lo­p­ment is not a sin­gle ‘thing’, but an idea or theo­ry, that invol­ves the approach to how soft­ware is developed.
Many web­sites and arti­cles talk about the dif­fe­rence bet­ween ite­ra­ti­ve soft­ware deve­lo­p­ment and incre­men­tal soft­ware deve­lo­p­ment, but the two are not necessa­ri­ly mutual­ly exclusive.
Of cour­se, it is important to note that ite­ra­ti­ve soft­ware deve­lo­p­ment can be view­ed from one of two ways; eit­her from the developer’s per­spec­ti­ve or from the developer’s team leader’s per­spec­ti­ve. Each pro­vi­des a sub­stan­ti­al and legi­ti­ma­te view, yet dif­fe­rent and unique.

But it is rare the­se days that just one or the other pro­cess is used. Most soft­ware deve­lo­pers, inclu­ding tho­se who con­si­der them­sel­ves to be purists of ite­ra­ti­ve soft­ware deve­lo­p­ment, are most­ly pro­bab­ly using a com­bi­na­ti­on of both. To be spe­ci­fic, ite­ra­ti­ve soft­ware deve­lo­p­ment is focu­sed on steps or pha­ses of soft­ware deve­lo­p­ment. One way to descri­be it is not finis­hing one fea­ture or com­po­nent in one go. In other words, you code, get feed­back, code, get feed­back, etc.

Ano­t­her, much broa­der way of describ­ing the pro­cess, is that an ite­ra­ti­on is a short peri­od that could take one to two weeks or even three to six weeks, whe­re the soft­ware deve­lo­p­ment team takes a new idea, be it a cus­to­mer request or sto­ry and imple­ments it as, i.e., builds it as run­ning tes­ted software.
During this peri­od, many things take place: design, tes­ting, ana­ly­sis, coding, feed­back, etc. This is dif­fe­rent from incre­men­tal deve­lo­p­ment but only slight­ly, and in actua­li­ty it depends on how the soft­ware engi­neers or deve­lo­p­ment team see it for them­sel­ves. In other words, the two terms of ite­ra­ti­ve and incre­men­tal soft­ware deve­lo­p­ment are not mutual­ly exclusive.

The bene­fit of using ite­ra­ti­ve soft­ware deve­lo­p­ment, or at least the ite­ra­ti­ve approach to soft­ware deve­lo­p­ment, is that sta­ges of deve­lo­p­ment can over­lap. This means that while you are doing end-to-end tes­ting, you can begin to pre­pa­re new requirements.
This means essen­ti­al­ly that once a ver­si­on is com­ple­te, it can then be tes­ted and put through a review pro­cess, which results can be then trans­for­med or rather, rebuilt into a new ver­si­on (ite­ra­ti­on) of the component.

So then what are the real-life bene­fits of ite­ra­ti­ve soft­ware development?

For one, if done cor­rect­ly, it allows for mea­su­ring pro­gress and kee­ping plan­ning simp­le and reliable.

How does this work?

By not sche­du­ling pro­gramming tasks in advan­ce, the team or per­son is for­ced to plan out what will be done in each ite­ra­ti­on (peri­od). Addi­tio­nal­ly, this will assist in stay­ing abre­ast of ever-chan­ging user requirements.
Second­ly, by sti­cking to the ite­ra­ti­on plans stead­fast­ly, it will be seen immedia­te­ly, if any task may not be finis­hed on sche­du­le. At that point, it will be easy to re-esti­ma­te or rede­fi­ne and eit­her remo­ve or modi­fy some of the tasks.
What is cru­cial­ly important is to con­cen­tra­te the effort on com­ple­ti­on of the essen­ti­al tasks – tho­se defi­ned by your cus­to­mers – as oppo­sed to tho­se pos­si­b­ly incom­ple­te tasks which were cho­sen by the developers.
This, in a nuts­hell, is a very brief insight into the aims and pur­po­ses of ite­ra­ti­ve soft­ware development.