jrothman.com - How Good is Your Backlog. Start with Ready Criteria, Part 1

Tip

Explores “Ready Criteria” as a tool to ensure backlog items are actually actionable before a team starts work. Key elements include ensuring the team understands the problem/outcome (not just the solution), identifies necessary expertise, and can bound the work within a few days. Emphasizes that setting strategic context and thinking in “feature sets” is essential for effective backlog management.

Does your team feel as if they can’t really start when they take an item off the backlog? The team says the item feels too big. Or the team realizes they need someone else from some other team to solve this problem. Worse, the team needs to decompose the item more to make sure they know what the problem is and then how to deliver it.

Those backlog items are not ready to start. Yet, too many teams (or product leaders) put those items on the backlog anyway.

That’s because too many Scrum boards have just three columns: Backlog, In Progress, and Done. That’s not enough information for most teams. So the team can’t really start.

However, you have options:

• Create a definition of what Backlog or Ready means.
• Learn to shape or right-size the work with the entire team.
• As the team shapes or right-sizes, learn when this team needs someone else (or another team) to finish this item.

I’ll start with the definition of Backlog or Ready, how to know a backlog item is ready for the team to work on.

Idea 1: Define Ready Criteria

Scrum Board from Create Your Successful Agile Project

Ready means “Ready to Start.”

This image is the default Scrum board I used in Create Your Successful Agile Project. Notice it has three columns: Ready, In Progress, and Done.

If you use a board like this, you can define what Ready means. Even if you use a board where the left-most column is called “Backlog,” you can define what that term means.

Here are some candidate criteria for what Ready means:

• The team knows the problem they need to solve and the desired outcome. (Not how they will implement the solution to this problem. The team gets to decide that. But they know the problem and the effects of solving that problem—what the user can do next.)
• The team has some idea of the expertise it needs to solve this problem. If that person is inside the team, that solves the “we need another person” problem. If the team does not have access to that person, that’s an impediment the team facilitator, such as a Scrum Master or agile project manager, can fix.
• The team can complete this work in some upper-bound number of days. While I love oneor two-day stories, your team might prefer fouror five-day stories. If your team prefers fouror five-day stories, you only need to create two stories per two-week iteration. That simplifies all of your planning.

Your team might need other criteria. That’s fine. As long as the team knows that everything in the Backlog or Ready column is ready to start.

However, there’s one more step before the team can shape the work: set the context for the backlog items. Are the backlog items part of a feature set? Or are they independent or one-off features?

Set the Context for the Backlog Items

How well does your product leader set the context for the backlog items? That is the product leader’s job. Not to generate all the stories alone, but to make sure the product leader and the team generate the stories together. Sometimes, that means the product leader needs strategic or tactical support from others in the organization. (See the series that starts with How to Avoid Solo Product Leadership Failure with a Product Value Team, Part 1.)

![Possibly Random Week of Work as a Roadmap](../../assets/6169971f578ef3f6184c1f1a12db4a61_MD5.png I am not fond of “backlogs” with no apparent strategic value. That’s why we need Effective Project and Program Management.

This image with the many colored boxes shows two possible scenarios:

• If each line is a person, that person works on different feature sets for a month or more.
• If each line is a team in a program, that team works on different feature sets for a month or more.

How do teams manage their multitasking if they’re supposed to move from product to product in an iteration? How can a team finish any given product?

They can’t.

It’s possible the organization got itself in trouble with too many projects and programs in progress. See One Quick Way to Start to Manage Your Project Portfolio for ways to get out of that trouble. In the meantime, choose one product (one color in the image above), finish enough of that to stop, and then move to another product. Do that until the team can work on just one product at a time.

And, always make sure the team knows enough about this product to know what Ready means.

The team might need a mid-iteration decomposition workshop to refine those items in Ready. That requires that everyone think in feature sets. See Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets. (Page down to the “Brainstorm” part of that post for the workshop.) I’ll discuss more about that in the second part of this series.

The Entire Backlog Series

• How Good is Your Backlog? Start with Ready Criteria, Part 1
• How Good is Your Backlog? How to Shape the Work for Product Success, Part 2
• How Good is Your Backlog? How to Assess the Necessary Team Skills, Part 3