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.
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 ‘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:
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 (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.
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.
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 ‘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
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 (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.
No comments:
Post a Comment