Mike Cohn has a good blog post about this, here.
I will agree and then slightly disagree.
Release Planning I think should normally mean planning the next release. So, as Mike says, we are looking ahead a few sprints (1 or 3 or 10 or …), to get an idea what features we expect to include in that release. Or to see if the features we ‘need’ to release can be released by that date.
In agile, we assume nothing is fixed. In the sense that everything has some degree of negotiability. If it needs to. And we assume that everything changes, nothing remains the same. As the Buddha said 2000+ years ago.
But, when I (and others?) use the term we mean something a bit different.
We mean a set of tools and techniques, and a way of thinking, about how to plan the product. Short-term and longer-term. And how this planning will feed the sprints (where we have ‘sprint planning’). We do ‘release planning’ to feed the sprints.
‘Garbage in, garbage out’ we have heard many times. So we are trying to feed good stuff into the sprint, so that good working product comes out of the sprint.
So, does ‘release planning’ go away? Well, the same tools and techniques may not be needed at all in some situations. This is true.
But usually, most firms have a lasting, evolving product. So ‘release planning’ (where you have one or more releases every sprint) becomes ‘product planning’ over multiple releases. And essentially the same tools, techniques and ideas apply. ‘A rose by any other name would smell as sweet’ as Shakespeare said.
Do I want to stop using the term ‘release planning’? No. Because it is still useful to most people, I think. But more and more I want to discuss the issues mentioned here, when I use the term.
For the longer view, Jeff Sutherland likes the term ‘product roadmap.’ He thinks most firms need a product roadmap that gives them an idea how the product will likely evolve over the next 12 months (some products less time, some products more time). This seems like a sensible idea to me.
***
Guarantee, predict, estimate, commit, forecast. Be very careful with these words. Or similar words. Do not mis-lead or mislead people.
‘To predict is difficult, particularly of the future.’ This was said in Latin some 2000 years ago. And remains true today, maybe more true.
Managers: It will not help you to drive a ‘death march’ or anything like it. Not to mention that it is immoral. They are not your slaves. Almost always, if you think they are lazy, then you have been too lazy to work with them closely. Almost always, it is your fault that their work situation is so disrupted that they can barely get anything across the goal line for the customer.
Workers (if we may divide the world into managers and workers): Do not say things that the managers can easily mis-understand. Tell the truth. ‘No’ is often the right answer. Do not use weasel words that, to you, mean ‘no’, but to the managers are often heard as ‘yes’.
I will agree and then slightly disagree.
Release Planning I think should normally mean planning the next release. So, as Mike says, we are looking ahead a few sprints (1 or 3 or 10 or …), to get an idea what features we expect to include in that release. Or to see if the features we ‘need’ to release can be released by that date.
In agile, we assume nothing is fixed. In the sense that everything has some degree of negotiability. If it needs to. And we assume that everything changes, nothing remains the same. As the Buddha said 2000+ years ago.
But, when I (and others?) use the term we mean something a bit different.
We mean a set of tools and techniques, and a way of thinking, about how to plan the product. Short-term and longer-term. And how this planning will feed the sprints (where we have ‘sprint planning’). We do ‘release planning’ to feed the sprints.
‘Garbage in, garbage out’ we have heard many times. So we are trying to feed good stuff into the sprint, so that good working product comes out of the sprint.
***
I have to agree with Mike completely on this: More people are
releasing faster now. Often every sprint. This is great, almost always.So, does ‘release planning’ go away? Well, the same tools and techniques may not be needed at all in some situations. This is true.
But usually, most firms have a lasting, evolving product. So ‘release planning’ (where you have one or more releases every sprint) becomes ‘product planning’ over multiple releases. And essentially the same tools, techniques and ideas apply. ‘A rose by any other name would smell as sweet’ as Shakespeare said.
Do I want to stop using the term ‘release planning’? No. Because it is still useful to most people, I think. But more and more I want to discuss the issues mentioned here, when I use the term.
For the longer view, Jeff Sutherland likes the term ‘product roadmap.’ He thinks most firms need a product roadmap that gives them an idea how the product will likely evolve over the next 12 months (some products less time, some products more time). This seems like a sensible idea to me.
***
Guarantee, predict, estimate, commit, forecast. Be very careful with these words. Or similar words. Do not mis-lead or mislead people.
‘To predict is difficult, particularly of the future.’ This was said in Latin some 2000 years ago. And remains true today, maybe more true.
Managers: It will not help you to drive a ‘death march’ or anything like it. Not to mention that it is immoral. They are not your slaves. Almost always, if you think they are lazy, then you have been too lazy to work with them closely. Almost always, it is your fault that their work situation is so disrupted that they can barely get anything across the goal line for the customer.
Workers (if we may divide the world into managers and workers): Do not say things that the managers can easily mis-understand. Tell the truth. ‘No’ is often the right answer. Do not use weasel words that, to you, mean ‘no’, but to the managers are often heard as ‘yes’.
No comments:
Post a Comment