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

This content is syndicated from LeanAgileTraining by Joe Little. To view the original post in full, click here.

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, the community has 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.

But 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.


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 ‘release planning’ — the short, quick up-front activity of defining a product backlog and guessing at what the next release or 2 or 3 might look like.  And maybe some other things. Not all teams need release planning I guess, but in my personal experience, virtually all teams the teams I have worked with have needed some short quick up-front release planning.

In any case, we have some sort of product backlog. And, 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?  (Well, the true root cause of course is ‘change’ very broadly speaking.  But you know what I mean…)

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.

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

  • breaking down 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.


Usually they are not doing, or not doing effectively, the longer-term activity of managing the product backlog toward success in the release (and here I am assuming that 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.

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 connotations. Of professionalism, of robustness, of having to be on top of it all the time. But also of balance and cost-benefit approach and 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 Release Plan closer to what we will do to make the release successful.  So they can say tp themselves: ‘yes we have initial release planning… but immediately we embark on continuous release plan refactoring to make the RELEASE successful.’

Release Plan Refactoring also includes the ‘getting ready for the next sprint planning meeting’ stuff too. It include 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.  And 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, really, 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 booklet “Joe’s Agile Release Planning”.  Available here.

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × 5 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch