Grooming and Definition of Ready

A couple weeks back, I had a meeting with a team member. Let’s call him Ted. Ted raised some concerns with me as to the team's current practices. I took down all the concerns and used a prioritizing strategy to help him decide which of these concerns was the most important to address right away.

Ted decided the most critical concern was that the team had work spilling over from one sprint into the next. They were never able to complete all of their work within their sprint and the overflow made them fall further and further behind.

I asked some more probing questions, and he mentioned that in many instances there were external dependencies with the issues in the sprint. The team was attempting to resolve these dependencies within the sprint and were getting blocked when they weren't able to get the information that they needed in a timely manner. They were still trying to establish an understanding of these issues midway through the sprint.

My team had fallen into a bad habit of treating backlog grooming meetings purely as a ceremony where the development team discusses a bug or story just enough to be able to provide the Product Owner with an estimate, then move on to the next issue.
Also, this meeting only took place for one hour once per sprint.

I’ve been tracking this as an issue for a little while. I thought this was the case and had a meeting with each of my 4 teams. I called the meetings ‘design discussions’ because I didn’t want the teams to fall into their backlog grooming habits.
In each of these meetings we took the next item outside the current sprint that was highest priority and talked about it from a number of different angles.

An interesting takeaway is that we discovered new acceptance criteria in 3 of 4 issues. We found that one of the issues had a ‘Found in Version’ for a release that didn’t exist. We also had some good conversations about the testing strategy for each of these issues.

Each issue was updated to include all of our findings, discussions, acceptance tests, and more. This all reinforced my belief about how the teams treated backlog grooming meetings.

I knew that more effective backlog grooming meetings would be the venue for this missing work, but I needed to pair it with a Definition of Ready.

A Definition of Ready can be considered a checklist of everything that has to be considered before an issue can be considered Ready to be included in a sprint. As such, providing an estimate for the work is a single checkbox on this list.

A backlog grooming meeting, paired up with a Definition of Ready can lead to effective use of our time.

I directed them to the Definition of Ready and asked them to use it for a couple sprints to understand how it works for them and the work they were analyzing, then after some experience with it, make it a topic within a sprint retrospective to make tweaks so that it’s more useful for the team and the product.

In addition to that, I asked this team member’s team to have a 1-hour backlog grooming meeting every two days. At the end of the backlog grooming session, they will assign an upcoming item in the backlog to each team member who will spend one hour on the off day digging into the code, analyzing the issue, and putting some thought into it.
This is done so that they can present what they’ve learned about that issue in the backlog grooming session. This also provides for a built-in agenda which can keep them on track.