top of page
  • Medium
  • Linkedin
  • Twitter
Search

Backlog readiness checklist

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

References:

Comments


bottom of page