AGILE IN ACTION

Monday, 23 January 2006

Planning with the Horizon of Predictability

Posted by Simon Baker

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 .


Creative Commons Licence

Recent Posts

  1. Pursuing features increases total cost of ownership
  2. Organization complexity is a waste farm
  3. Managing costs provides a false sense of security
  4. State of Agile survey for 2011 tells a familiar story
  5. (I can't get no) satisfaction, let alone customer delight
  6. Positive emotions and purpose
  7. People don't buy what you do, they buy why you do it
  8. Too busy chopping wood to sharpen the axe
  9. So you want a fresh apple
  10. Systems are seductive

Archives

  1. 2012 (6)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
  7. 2006 (128)
    1. December (16)
    2. November (26)
    3. October (7)
    4. September (11)
    5. August (7)
    6. July (7)
    7. June (4)
    8. May (4)
    9. April (4)
    10. March (4)
    11. February (14)
    12. January (24)
      1. Look after your product backlog
      2. 1-week iterations
      3. Root cause analysis using 5 Whys
      4. Agile In Action is now available at Artima
      5. Planning with the Horizon of Predictability
      6. The knowledge worker and the new organisation
      7. Setting Norms to help internalise Agile values
      8. Agile is ... Agile isn't ...
      9. It doesn't have to be about business value
      10. Task-switching is waste
      11. Flow, ideal time and the E-factor
      12. A Scrum Master is like a music conductor
      13. Slack != Waste
      14. Go on. You know you want to. Say 'Hello'
      15. Spike
      16. Why agile principles are important
      17. Pareto Principle
      18. My interaction style
      19. An 'aeroplane in flight' metaphor for agile tracking
      20. A Scrum Master is like a skilled helmsman
      21. Fun and games
      22. Innovation games from enthiosys
      23. Thomas Edison on 'Lean'
      24. The speed of thinking
  8. 2005 (63)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (39) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (18) team (30) testing (18) xpday (19)