As you get to the end of the year, it can be natural to think about the roadmap for following year. What will 2013 bring? What are the goals and KPIs?
I was in such a meeting discussing the roadmap when someone mentioned a weather report. That got me thinking. Roadmaps and software delivery plans are very much like weather forecasts.
All you know for sure is the current weather. It is raining outside is equivalent not to the state of your issue tracker, but of the running product.
As soon as you go forward in time you are guessing, so don’t kid yourself. You may have a good idea on what will be done in a sprint, in the same way that the 5 day forecast can be pretty good.
In software there are also multiple glimpses into the future via the branches that you have going. That pull request from Bob that adds featureX is one example of a future peak at when you go through a code review and probably eventually merge it into master, or a release branch.
Although there is an inverse relationship between the delta in time from now and the likelihood of the forecast is correct, that doesn’t mean it isn’t worth doing. We still use long range forecasts, but they are different types of measuring sticks. For example, you may want to ask
“I want to go to Costa Rica in February, what is the weather likely to be like then?”
You can statistically have a view point. On the software side you can get good at measuring a) your team, b) scope, and c) the risks in the project. This shouldn’t be confused with “knowing”. In fact, it isn’t worth going into intricate detail on each item and scoping it out for the next year to get a conclusion, as that is only one reality that you are mapping (this is why I prefer LiquidPlanning for this kind of work btw, to get a model vs. one path). You care more about the trends.
So, the next time someone asks you for a year long roadmap, maybe show how the probability changes over time and making it crystal clear how you are playing the role of a meteorologist.