Development

Iteration Backlog

The Iteration Backlog is a sub­set of the prod­uct back­log. It only in­cludes the tick­ets in­tended to be com­pleted within the it­er­a­tion. Once these tick­ets are com­pleted, it will re­sult in a new ver­sion of the ap­pli­ca­tion be­ing ready for test­ing. An it­er­a­tion can be made up of any ticket de­fined within the prod­uct back­log or any newly dis­cov­ered tick­ets. All tick­ets en­ter­ing the it­er­a­tion back­log must pass a qual­ity gate be­fore an it­er­a­tion com­mences.

It is rec­om­mended to keep the ticket work­flows sim­ple; these will be the day-to-day processes that de­vel­op­ers fol­low when com­plet­ing their it­er­a­tion work. Over-engineering these, can very eas­ily re­sult in trou­ble with or­gan­i­sa­tional adop­tion, or missed steps. The fol­low­ing is a stan­dard and widely adopted four-step process:

• To do: Work that is yet to be started by any de­vel­oper.

• In progress: Work that is cur­rently in progress by a de­vel­oper and should be as­signed as such.

• Review: Work that has been ten­ta­tively com­pleted but is await­ing peer re­view from an­other de­vel­oper.

• Done: Work that is been com­pleted and passed the it­er­a­tion re­view process.

To vet is­sues that en­ter this work­flow, it is rec­om­mended to en­force a Definition of Ready. This will en­sure that tick­ets are prop­erly pre­pared for de­vel­op­ment. The best time to check the de­f­i­n­i­tion of ready is dur­ing the plan­ning ses­sion. If gaps are found, they should be rec­ti­fied prior to the start of an it­er­a­tion to mit­i­gate po­ten­tial is­sues. Key points to ex­plore with a de­f­i­n­i­tion of ready should be ticket qual­ity, siz­ing, risk level and the ex­is­tence of sup­port­ing arte­facts (for ex­am­ple, has it been de­signed in the pro­to­type).

Conversely, pro­gress­ing an is­sue through to “Done” should re­quire a Definition of Done, which is used to en­sure all tick­ets com­pleted meet a de­fined stan­dard. When a ticket is fin­ished, it is rec­om­mended to check that peer re­view has been per­formed, the fea­ture has been ap­pro­pri­ately tested, ac­cep­tance cri­te­ria has been met, and it is ready to be re­leased.