Planning isn’t predicting

Neil Killick
Nov 1, 2019 · 4 min read
Image for post
Image for post

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.

If you have any questions about any of the concepts in this article, or need a hand with your service design, lean/agile product development or agile transformation endeavours, please reach out directly to me or my company Hypothesis.

The Startup

Neil Killick

Written by

Executive Agile Coach ⍟ Expert Scrum/Lean/Agile Software Product Development Practitioner ⍟ Digital Product Owner

The Startup

Medium's largest active publication, followed by +773K people. Follow to join our community.

Neil Killick

Written by

Executive Agile Coach ⍟ Expert Scrum/Lean/Agile Software Product Development Practitioner ⍟ Digital Product Owner

The Startup

Medium's largest active publication, followed by +773K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store