Backlog readiness checklist
- Igor' Arkhipov
- Jan 26, 2022
- 2 min read
Make sure your product backlog is in a good state for your team to commence development.

Problem statement
This issue of our quick bites addresses a problem: “How might we ensure the backlog is in a good enough state for the team to work with it?”. A question that a lot of BAs and product owners ask themselves.
Checklist
There are many things to take into account when developing a product backlog for the team. You may follow some of my previous advice [1] on the matter, or you may come up with your own rules.
The checklist below is a good self-reflection exercise to sense check if the backlog that you’ve got is going to be fit for purpose.
Note, that all the projects are different, so some of the questions may need to be adapted to your specifics.
The backlog is ready
The backlog is ready for the development to commence when you answer YES to all of these questions:
Fixed-scope project: Do all the backlog items meet the Definition of Ready?
Flexi-scope project: Do at least the first 2–3 sprints of backlog items meet the Definition of Ready?
Do all the backlog items structurally follow the corresponding templates?
Do all the backlog items belong to corresponding epics?
Are all the backlog items in the Definition of Ready state estimated?
Is the team confident the backlog covers all that needs to be delivered?
Is the backlog signed off or otherwise endorsed by the client/sponsor/key stakeholders as a good enough reflection of the ?
Are backlog items grouped into releases?
When a team member reads a ticket, do they understand what they need to do?
Does a solution architecture exist to accompany the backlog items?
Specifically for content management systems (CMS) projects:
Fixed-scope: is the final list of authorable and non-authorable content components defined?
Flexi-scope: are existing backlog items allocated to components?
The backlog is not ready
The backlog is not ready for development if even one of the following is true:
Backlog items are just titles with no details
Backlog is not organised into epics/themes/releases
Backlog is not estimated or is not estimable in general
Client/sponsor/key stakeholders haven’t seen the backlog
Team members don’t understand what is written in the backlog items/ don’t know what to do or where to start to deliver them
No acceptance criteria exist or acceptance criteria are too broad or seem to be outside of scope of the project
Backlog items are not linked to solution architecture / design / customer research / client supplied documentation
Comments