How to work with a backlog and develop criteria for completion
As part of the scoping process, a Requirements Backlog is gathered with a core output being a list of work to perform. Within active development this list is generally managed into a series of issue types that guide our workflow:
- Epic: A high-level theme or feature that is used to categorise related stories, tasks and defects.
- Story: A fine-grained requirement, written from a user’s perspective, that is small enough that it can be logically estimated and built within a short period.
- Task: A work item that isn’t written from a user’s perspective and is instead a technical item required to achieve the applications stories.
- Defect: A work item typically related to an epic, that has arisen as a result of application testing, which can be a technical bug in the application or a usability issue.
- Spike: Typically, a time-boxed work item with a learning goal associated with de-risking some technology or concept.
It is generally recommended to keep ticket workflows simple; these will be the day-to-day processes that developers follow when completing their 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 working:
- 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 workflow, it is recommended to enforce a Definition 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 rectified prior to the start of an iteration to avoid issues arising. Key points to explore with a definition of ready should be ticket quality, sizing, risk level and the existence of supporting artefacts.
Conversely, progressing an issue through to “Done” should require a Definition of Done, which is used to ensure all tickets completed meet a defined standard. When a ticket is finished, 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.