If Agile is a team sport, then the product backlog is the ball

Chris Waggoner is a friend and colleague of mine. He is a CSC, Certified Scrum Coach, and a very experienced agile practitioner.

He sent me the following snippet in an email that I wanted to share:

"If Agile is a team sport, then the product backlog is the ball." - Chris Waggoner

I'm trying to get a group of PO's to realize that they should not attempt to complete a product backlog on their own but they should seek help at every phase of grooming stories and massaging the backlog.  On the flip side I'm trying to involve teams who believe it’s the Product Owners responsibility to bring them a completed, ready to consume story that they to are responsible for the completeness of stories and the state of the backlog.  This metaphoric phrase above came out of my mouth and it made sense to everyone once it did.

Chris Waggoner, CSC

Managing Consultant | SolutionsIQ

It was unsolicited, but nicely aligns with my own thinking.

A Metaphor

I think the metaphor works quite nicely. In a recent blog post, I discussed an article by Mike Cohn. You can read it here.

In the article, I was emphasizing really two key points:

1. I believe that Backlog Refinement is a whole-team ceremony, and
2. I believe that the team should look-ahead some number of sprints while refining the backlog

Chris’ metaphor nicely supports this idea. In team sports, you spend an inordinate amount of time “with the ball”. I’ll take basketball as an example. You dribble it, you pass it, you shoot it, and you rebound it.

You practice these things as a team. Sure, sometimes you do drills that only involve 1-2-3 people, but they’re within the team context.

Some Reactions to my Mike Cohn article

Adrian Lander, Lean Agile Transformation / Exec Coach

I read Mike’s text and I have never been a groupie of anyone (that includes myself). I just find that quite often I agree with Mike. Maybe because we both have been in Agile for many years. And SW development before. On your two main points of disagreement.

(1)   Actually Mike is not saying that the refinement meeting is just tied to the next sprint. He is saying “getting ready for the next sprint”. It does not exclude that getting ready for the next sprint includes looking a bit beyond if that is part of getting ready. And in my and most probably Mike’s view, looking beyond is part of getting ready for the next sprint. I remember something like Mike’s rule of thumb of having ready stock for 2-3 sprints.

So in my view, you are taking a very restricted interpretation, which is not the intended reading, if you know the rest of Mike’s guidelines. He also refers to the top of the backlog, another indication. Logically, if you always get ready in time for the next sprint, the train never needs to halt – until validly stopped, e.g. ROI of next sprint is not sufficient. If that readiness includes sufficient look ahead, you should be in good shape.

(2)   Yes, team members can opt out of refinement meetings for valid reasons. You do not need everyone in every meeting. That is not very agile and potentially quite unlean – wasteful. Remember that any ready stories that will be pulled into a sprint will be discussed during sprint planning. Do you need to involve everyone in every step of the preparation by rule?! No. It’s non-agile and unlean. Especially as there is common sprint planning – which does require the entire team.

Yes, even the best can get it wrong. In my view it was not Mike this time. He actually got it right twice, in my personal view.

Mark Watson CSM, CSP

I think you are locally optimizing the team participation over the highest priority work. Agile is a Team sport and when possible the whole team should participate in the refinement. But, there are certainly plenty of times where 5 or 6 out of the 7 can be there and 1 or 2 others finish completion of the Iteration. The world isn't perfect and sometimes these hard decisions have to be made. If it happens too often, then the team probably has too much WIP each sprint. Personally, I prefer spreading the meetings over the sprint. Twice a week for an hour, but that is not an absolute. Sometimes we shift the meetings around time wise, but try to keep a consistent cadence.

I disagree quite a bit on having distant work be the most important focus of the refinement, especially if the whole team is there. These are the lowest priority items on the horizon and need the least amount of 'right now' refinement (they could be months away). They shouldn't be ignored, but these are excellent candidates for one or two of the team members to be investigating, time permitting, in advance.

My reactions

First of all, I really want to thank Adrian and Mike for commenting. They shared their thought on LinkedIn and I thought enough of them, to copy them here. While I don’t always agree with folks’ commenting on my writing, I do appreciate the dialogue.

But to answer Adrian & Mark, let me be clear…

Point one; I think teams have a responsibility to be refining their backlogs to some level of reasonable look-ahead. I would say, only refining for the next sprint (or sprint-at-a-time) is an agile anti-pattern. As would be refining 20-30 sprints ahead.

There’s a healthy balance that needs to be struck. To be honest, I actually don’t care about Mike Cohn’s advice in this case. My experience supports healthy look-ahead in backlog refinement, usually at a release level (one release ahead), as being a solid tactic within healthy agile teams.

Point two; I consider backlog refinement to be an entire team endeavor, similar to sprint planning or the daily stand-up. Can team members miss these meetings? Sure, but not because they’re “working on the sprint”. Just like the entire team has a responsibility to attend and engage in their daily stand-up, I feel the same level applies to refinement.

Now to be clear, when I say refinement, I really mean two sorts of activities:

1. There are whole-team meetings where the team discusses design, decomposes stories, writes acceptance criteria, explores estimates and generally gets a better understanding of the work associated with each story.
2. But there is also off-line work where small groups or an individual from the team explores stories.  But these discoveries are always brought back to the entire team and vetted with them.

I often reference the “up to 10%” of the teams’ time is spent in backlog refinement quote from Schwaber in the original Scrum book and by both Schwaber and Sutherland in the Scrum Guide. I usually recommend that a team scheduled 2, 1-hour meetings a week for refinement activity as a group. With the remainder of the up to 10% time being spent by individuals or sub-teams exploring the backlog.

It’s this dual-focus that, in my experience, gets the best results.

Wrapping up

At the end of the day, I’m not:

• Arguing against Mike Cohn’s recommendations or experience;
• Nor am I arguing with Adrian or Mark;
• Nor am I telling you specifically what to do.

I’m simply sharing my experience; both in the trenches experiences and experiences coaching agile organizations and teams.

To me, refinement is a “pay me now” or “pay me later” investment. I’ve found that if your team is doing sufficient refinement, then:

• the sprint planning meetings are incredibly smooth, focused, and short, and
• the sprint results are usually better – less dependencies, less confusion, and far less challenges.

Conversely, if you short shrift this advice, often planning is a mess and the results, well, are less then optimal.

The choice is yours…

Stay agile my friends,

Bob.