Planning with the Horizon of Predictability

Planning is everything. Plans are nothing. - Field Marshall Helmuth Graf von Moltke

The further you plan into the future the less predictable things become. Change will inevitably happen and the 'where', 'when', and 'how' cannot be anticipated. There's a point where predictability moves into uncertainty. This is called the Horizon of Predictability. You can see clearly up to this horizon but not beyond it.

Therefore, you can plan in detail up to the horizon and expect things to remain reasonably stable. But when you move beyond the horizon you should plan with a decreasing level of detail and precision as things become less certain and more unpredictable. As time progresses the horizon shifts into the future by the same amount. Previously uncertain things move into the predictable zone as new information comes into focus and is understood. Because the planning landscape changes over time, you need to look out to the horizon frequently, assess what is known and what is not known, and adjust your plans accordingly.


horizonofpredictability
Originally uploaded by sjb140470.

When you plan a release you are determining how many user stories can be completed in the allotted timeframe. The release plan looks the furthest out and uses the least detail and precision. Consequently, it should be reviewed and updated at the start of each iteration to ensure that it continues to reflect what is believed to be the achievable target content for the release.

Iteration planning doesn't look beyond the horizon. It focuses on the user stories selected for the next iteration only. This is planning close-up, where things are predictable. The iteration plan is more detailed than the release plan and disaggregates the selected user stories into the engineering tasks needed to produce running tested features. At the start of each iteration, it's worthwhile re-assessing the release plan, based on information revealed during the last iteration, to see if it needs to be adjusted.

On a daily basis there is a Stand-up or Scrum meeting where the development team gets together to coordinate their work for the day and synchronise their efforts. This provides a regular opportunity to assess progress against the iteration plan and make any necessary adjustments.

Setting goals that define a theme

It helps to set goals for releases and iterations that define a theme. Goals are more ambiguous than plans, which make them more resilient to change, keeping them stable and relevant over time. In Scrum, a Sprint Goal is defined at the start of a Sprint. Setting a Sprint Goal allows the Scrum Team to react to change within a Sprint by adjusting the planned work such that the Sprint Goal can still be achieved. This enables the team to still deliver the value desired by the Product Owner.

Where is your Horizon of Predictability?

It depends entirely on the volatility of your environment. How long can your customer last before he starts requesting that you do work not planned in the current iteration? How often do business priorities change? Do you need to be able to turn on a penny? In my experience, the Horizon of Predictability is seldom greater than one month. If it is, maybe your customer has forgotten about you and isn't interested in the project anymore.

Be aware of your Horizon of Predictability when setting your iteration length. You don't want to set your iteration length further out than your Horizon of Predictability. If you do, you're iteration plan is going to be unstable and the detailed planning you perform may be wasted.

Further reading:
1. Mike Cohn's Agile Estimating and Planning.
2. Mishkin Berteig's What to do with the Horizon of Predictability and Change is constant.


Tags: agile, adaptive planning

posted by Simon Baker @ permalink
blinklist : del.icio.us : digg : furl : simpy : spurl : reddit