Vision = reality
The Iteration Backlog is a subset of the product backlog. It only includes the tickets intended to be completed within the iteration. Once these tickets are completed, it will result in a new version of the application being ready for testing. An iteration can be made up of any ticket deﬁned within the product backlog or any newly discovered tickets. All tickets entering the iteration backlog must pass a quality gate before an iteration commences.
It is recommended to keep the ticket workﬂows simple; these will be the day-to-day processes that developers follow when completing their iteration work. Over-engineering these, can very easily result in trouble with organisational adoption, or missed steps. The following is a standard and widely adopted four-step process:
To do: Work that is yet to be started by any developer.
In progress: Work that is currently in progress by a developer and should be assigned as such.
Review: Work that has been tentatively completed but is awaiting peer review from another developer.
Done: Work that is been completed and passed the iteration review process.
To vet issues that enter this workﬂow, it is recommended to enforce a Deﬁnition of Ready. This will ensure that tickets are properly prepared for development. The best time to check the definition of ready is during the planning session. If gaps are found, they should be rectiﬁed prior to the start of an iteration to mitigate potential issues. Key points to explore with a definition of ready should be ticket quality, sizing, risk level and the existence of supporting artefacts (for example, has it been designed in the prototype).
Conversely, progressing an issue through to “Done” should require a Deﬁnition of Done, which is used to ensure all tickets completed meet a deﬁned standard. When a ticket is ﬁnished, it is recommended to check that peer review has been performed, the feature has been appropriately tested, acceptance criteria has been met, and it is ready to be released.
It is imperative for developers working on an iteration together to review each other’s work. It ensures code quality and synergy as part of any workﬂow. Highlighted below is a guide of topics recommended for any peer review before a ticket moves through a definition of done. Keep in mind that it is not feasible to cover every topic for each ticket:
- Code quality
- Styling implementation
- Smoke-testing the application