Why I prefer ‘Release Plan Refactoring’ to ‘grooming’

October 12, 2013

I was just doing a course with Dave Muldoon in Canada. One of the workshops was scaling. In that context, we discussed release plan refactoring or product backlog grooming.

To me, the Scrum community has many definitions of ‘product backlog grooming.’ In fact, many different words for it. And it is confusing, especially to beginners.

I like to use the phrase ‘release plan refactoring’ instead.

Today, briefly, I wanted to explain why.

First, why is this question even important? Because ideas affect actions. If we do the action without a deep understanding of the intent, we are very likely to do the action in an ugly way.

Basics

The bare framework of Scrum does not define ‘release planning.’ Nor does it define ‘backlog grooming.’ The latest Scrum Guide does have a few vague phrases like this: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process….”

My understanding is that Jeff Sutherland and Ken Schwaber are not against doing specific things and using specific words in specific situations. They just feel that they don’t want to include those things in the bare framework of Scrum. Why? Well, that’s a lengthy conversation for another day.

Probably not all teams need what I call ‘agile release planning’ — the short, quick up-front activity of defining a product backlog and guessing at what the next release or 2 or 5 might look like. And maybe some other things. Not all teams need release planning I guess, but in my personal experience, virtually all the teams I have worked with have needed some short quick up-front release planning. (Note that I want ‘release planning’ to cover multiple releases, almost always. So, it’s a bit misnamed.)

In any case, we have some sort of product backlog. Clearly in real life and clearly according to the Scrum Guide, that product backlog must evolve.

What to call it

So, what should we call that activity that makes the product backlog evolve? (The true root cause of the evolution is, of course, ‘change’ very broadly speaking.)

PB Grooming:

To me that connotes two chimps grooming each other. I visualize grooming my face, or a man grooming his beard, or a beautiful woman putting on make-up, or grooming my toenails (sorry!).

When I see ‘regular’ teams do what they call grooming, it is mostly these things:

breaking down larger stories (or PBIs) into smaller stories (or PBIs)
Identifying new stories
adding Story Points to the new stories
adding acceptance criteria
more broadly: getting the top stories ready for the next sprint

And this is great. Very important. Useful, good.

BUT…incomplete.

Usually they are not doing, or not doing effectively, the longer-term activity of managing the product backlog toward success in the release (for the moment, I am imagining it takes 3 to 10 sprints to build the release).

PB Refinement

(The term in the Scrum Guide.) When people use that term and you watch what they do, they usually do (and say) about the same things as for PB grooming.

I believe Jeff Sutherland and his teams do something a lot closer to what I call release plan refactoring.

Note: There are many exceptions, of course, to how people use these terms. I am saying what I generally hear and see.

Release Plan Refactoring (RPR) – Why I like it

First, RPR suggests that the ‘whole’ release plan needs to be refactored. In every way.

In software development, the word ‘refactoring’ has a set of strong positive connotations. Of professionalism, of robustness, of having to be on top of it all the time. Also of balance and a cost-benefit approach and some other things. Almost all of these things apply, at least by analogy, to Release Plan Refactoring.

Also, to me, RPR helps express, to people in the Team and people outside the Team, one key idea. The initial release plan is never ‘good enough’, and we are always trying to make the Release Plan closer to what we will do to make the release successful. So they can say to themselves: ‘yes we have initial release planning… but let’s immediately embark on continuous release plan refactoring to help us make the RELEASE successful.’

Release Plan Refactoring also includes the ‘getting ready for the next sprint planning meeting’ stuff too. (This is sometimes call ‘pre-planning’ or the ‘pre-planning meeting.’) RPR includes the ‘short-term’ stuff as well.

To me, one of the key advantages of RPR is that it connects
(a) the longer-term thinking around ‘what does the release need to look like’ and
(b) the short-term thinking around ‘what will we do next sprint.’
To use two words, it connects tactics with strategy. Both are required to be successful.

And my feeling is…
(a) we could try to re-define PB grooming or PB refinement to include those ideas of connection, so that the community ‘gets it’ better, or
(b) we can start using a different word (well, 3 words, RPR) to express that idea.

Clearly, I think (b) is the better approach. Am I right? (You decide.)

Now, the words per se are not important. What is important is that people have the right ‘tacit knowledge’ when they take an action. They need to know, when they try to ‘improve’ the product backlog (the release plan), why they are trying to do it, and how all the different things inter-connect. For example, how the short-term stuff connects to the long-term stuff. How tactics connects to strategy, if I may use those words in this context.

***

If you are interested, I discuss the practices more in my new book on “Agile Release Planning”. Available here.