I came across
this post by prominent Agile expert Mike Cohn. Mike is an extremely knowledgable practitioner and consultant with a massive wealth of experience, and as such he is someone we should most certainly listen to, and from whom we can learn a great deal.
However, I would like to address something in this particular post; a mistruth which I think perpetuates a fundamental misunderstanding in our industry of what "planning" is and should be, particularly in the arena of agile software and product development.
This mistruth is that planning equates to "looking forward a handful (or more) Sprints and making a prediction of what would be delivered by then".
This is not what planning is about — or at least it is certainly not the primary purpose of planning.
Let's start with a Wikipedia definition of "planning":
"Planning is the process of thinking about the activities required to achieve a desired goal. It is the first and foremost activity to achieve desired results. It involves the creation and maintenance of a plan, such as psychological aspects that require conceptual skills."
As this definition correctly describes, planning is the act of figuring out what we need to DO to meet an objective, not "how much we can get done". Any "prediction" we want to take from planning activity is a by-product, not the reason we do it or the primary artefact.
If we reduce planning to, e.g. figuring out how many story points we can accomplish by a deadline, this line of reasoning is like saying "it will be a 5 hour drive" equates to planning a road trip. But this is absolutely not the case. Which car should we use? What do we need to take with us? Which roads will we drive on? Where do we need to turn off? What is the best time to leave? Where should we stop? Answering the questions about our options, and which ones to choose to determine our best way forward, is what planning is really about.
Proper planning, done frequently (as it is in Scrum and other agile methods and frameworks), is so critical, especially when employing an incremental and iterative way of working. But it seems folks are still being told to predict things as the focus of their planning activity rather than to actually plan how to do the work to meet the objective.
The whole point of having short planning and delivery cycles in e.g. Scrum is precisely because we don't want to be making predictions beyond a couple of weeks at most.
Empiricism, upon which Scrum theory is founded, is the opposite of being predictive. Once we have created our plan (Sprint Backlog), we are now implicitly saying "this is what we as a team plan to do within the Sprint (time constraint) to achieve the objective (Sprint Goal)". Sure, one could say that the output we are planning to produce is our "Sprint forecast", but that forecast is very much a by-product, and is by far the least important aspect of the planning activity and the plan created. Creating the ability to tune and adjust how we accomplish the Sprint Goal is far more useful (via outcome based goals and a culture which supports and encourages this), and showing people outside of the team at the end of the Sprint (in the Sprint Review) what we've done, and accomplished.
This approach is vastly different from putting an emphasis on "how much" we will get done. Planning is "what we will do" and "what we will achieve", not "how much we will do". This distinction might seem subtle or unimportant to some, but I would stress that it is of critical importance in our field.
In Scrum we Plan-Do-Check-Act in each and every Sprint. We create a plan at the start of the Sprint, and then we create a new plan in the next Sprint, and the next, etc. etc. We monitor progress toward our broader objectives primarily using empirical measures such as working product (software), customer usage, pirate metrics and so on, not on output delivered (it doesn't make sense to use output as our primary measure because Scrum is about optimising the value we are creating, and "highest priority" output as defined by us internally rarely equates to maximum value).
As such, "release planning" is not deciding how many cards or stories or points we can deliver by an arbitrary deadline. It's deciding what the focus of the release will be. What is the simplest useful slice of our product/service/offering we can build and release to a subset of (potential) customers. "When" is important of course, but in empirical process we fix the when to be a date/time in the near future (e.g. 2-weekly Sprint cycles, daily/weekly/monthly release cycles, etc.), then focus on delivering something useful within that constraint, within our control, before the uncertainty of our complex environment can kick our ass too much.
Prediction is entirely the wrong focus.