I did a session today at the Atlanta Scrum Gathering about 'Joe's Approach to Release Planning'. Jason Tanner asked "what about the product roadmap?" And his question made me realize that I have not said enough about that.
My quick thoughts.
1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years. I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.
2. What time span should the product roadmap cover? Yikes. This is a hard question with no perfect answer. Longer than the implementers want to think about and shorter than the 'planner' type wants. OK? For most products, about 1 year. For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases). For 'big' products, you might need multiple years.
3. The purpose of the product roadmap is not to be right. But to generate useful thinking about 'longer term stuff', and provide some context for shorter-term thinking. This is still adaptive planning, of course.
4. YAGNI. First, You Ain't Gonna Need It (YAGNI) has proven to be a pretty good principle. Stuff happens, things change (for good and bad) and most of the knowledge created to go down path A is now useless. This principle always tilts things towards less investment in longer term planning. But of course, this principle is not the whole story.
5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose. "We are building the iPad1 as a step toward the iPad4."
6. Identify hard-to-reverse decisions. Many decisions or actions are easy to reverse. Some are quite hard. The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right. A product roadmap can help us identify those kinds of decisions, and put them in a context. For example, help us understand when those decisions must be made. What I am saying here is very similar to the Poppendiecks' 'decide at the last responsible moment' concept.
7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting. And then later build out the rest of the product roadmap.
Why? Because they don't really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring. It's a think-do feedback loop. They need to experience the "do" part sooner. Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.
***
Comments?
My quick thoughts.
1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years. I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.
2. What time span should the product roadmap cover? Yikes. This is a hard question with no perfect answer. Longer than the implementers want to think about and shorter than the 'planner' type wants. OK? For most products, about 1 year. For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases). For 'big' products, you might need multiple years.
3. The purpose of the product roadmap is not to be right. But to generate useful thinking about 'longer term stuff', and provide some context for shorter-term thinking. This is still adaptive planning, of course.
4. YAGNI. First, You Ain't Gonna Need It (YAGNI) has proven to be a pretty good principle. Stuff happens, things change (for good and bad) and most of the knowledge created to go down path A is now useless. This principle always tilts things towards less investment in longer term planning. But of course, this principle is not the whole story.
5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose. "We are building the iPad1 as a step toward the iPad4."
6. Identify hard-to-reverse decisions. Many decisions or actions are easy to reverse. Some are quite hard. The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right. A product roadmap can help us identify those kinds of decisions, and put them in a context. For example, help us understand when those decisions must be made. What I am saying here is very similar to the Poppendiecks' 'decide at the last responsible moment' concept.
7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting. And then later build out the rest of the product roadmap.
Why? Because they don't really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring. It's a think-do feedback loop. They need to experience the "do" part sooner. Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.
***
Comments?
No comments:
Post a Comment