As Project Managers, ScrumMasters, and/or Product Owners we all know how important the various Scrum ceremonies are. One attribute of Backlog Refinement that I’ve found particularly helpful is the creation of a “Ready List.”
The Ready List is comprised of at least two sprints worth of development-ready Product Backlog Items (PBIs).
Here’s a few tips on how to make and keep a Ready List:
It needs to be ready, to be a Ready List
This may go without saying, but a Ready List needs to be ready for development. Think of it this way: Those PBIs should be so entirely complete that the team could start work right now and successfully complete it. That means each PBI in your Ready List has its use case (or user story), acceptance criteria, supporting docs, exclusions, attached designs, assigned to its respective epic/version/test case, and story points.
Location, Location, Location
Keep your Ready List in one of two places. Either at the top of the Product Backlog or broken out in a section called “Ready List.” At DevelopmentNow we use Atlassian’s JIRA in our projects. I prefer to break out and rename a separate container as “Ready List” and move it above the backlog. This acts as a nice spot to glance at the most important PBIs in the backlog.
How PBIs make it into the Ready List
After the Product Owner has ordered the backlog, the delivery team pulls two sprints worth of PBIs into the “Ready List” container. You still keep your backlog ordered, but nothing gets moved into the Ready List until it meets two criteria.
1. It’s actually ready for development (see above)
2. It’s taken from the top of an ordered backlog
To put it another way, the topmost PBI in your backlog is next in line to be moved to the Ready List. Your job at each backlog refinement meeting is to make sure the Ready List stays stocked with at least two sprints worth of work.
Why this list is so useful
Ever jump into Sprint Planning and end up refining the backlog for most of the time? That could be a symptom of a not well prepared backlog. Part of having a prepared backlog is having a Ready List. While in Sprint Planning, let the team pull as much as they want into the sprint from the Ready List. You already know those items have been well fleshed out and are trustworthy PBIs.
In addition, the Ready List gives your Product Owner and other stakeholders a more concrete view into what development is scheduled over the next two sprints. Which is a pipeline anywhere from two weeks to two months worth of work.
Ready List FAQ
1. Can my Product Owner or ScrumMaster move items in and out of the Ready List?
Of course! Just make sure to follow the two Ready List criteria (above) when doing so.
2. Can I put more than two sprints worth of work into the Ready List?
Sure, but the more you put into that list the less accurate it’s going to be (in regards to upcoming work). I recommend keeping it to two sprints.
3. What if those PBIs need to change after we’ve moved them into the Ready List?
If the change is substantial, move it out. If it’s not, then leave it there and make the change. Just be sure to update all the pieces impacted (test cases, docs, etc).
