Release Planning: Product Roadmap

May 9, 2012

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, 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’ types want.  OK, for a typical product, 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 precisely right. One purpose is to generate useful thinking about ‘longer term stuff’, and provide some context for shorter-term thinking.

4. YAGNI.  First, You Ain’t Gonna Need It has proven to be a pretty good principle.  Stuff happens, and all the details created to go down path A is now (often) useless as you go down path B.  This principle always tilts things towards less investment in longer term planning.  But of course, this principle is not the whole story.

To the degree YAGNI is true, then the Product Roadmap is shorter and higher level (less granular) and done more quickly.

Bear in mind: The Roadmap is much more about the learning during the planning, than about ‘the plan.’ ‘Plans are useless, planning is everything.’

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.

6. Identify hard-to-reverse decisions.  Many decisions or actions are easy to reverse. Some are quite hard (costly, time-consuming, etc.) to reverse.  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 prefer to plan initially with about 6 months worth of work (typically one or two or three 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 (I am imaging a 1 year roadmap).

Why? Because as beginners, 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 (every Sprint).  It’s a think-do feedback loop. They need to experience it sooner.  Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.

***
Comments?

 

« « John Kotter Explains the 8 Steps to Create Successful Change || Killing Babies or Sizzling Steak? » »

Posted in: Better Agile, Release Planning
Tagged: Tags: , , , ,

3 thoughts on “Release Planning: Product Roadmap”

  1. Pingback: Release Planning: Risks, Dependencies, Learning, MMFS and Other | LeanAgileTraining

  2. Pingback: Release Planning: Completing the Plan | LeanAgileTraining

Leave a Reply