Tag: adaptive-planning
Thursday, 9 February 2006
User stories part 2: Adaptive planning
Posted by Simon Baker
Planning in detail too far into the future can be wasteful because changes will inevitably happen and they can't be predicted. The horizon of predictability marks the point where predictability moves into uncertainty. This horizon is the duration of an iteration. It's safe to plan in detail up to the horizon, but beyond it you should plan with a decreasing level of detail and precision. Adaptive planning defines a high-level plan or roadmap that contains the user stories to be developed over a distance such as a release, and creates a detailed plan for the next iteration only. User stories are well suited to adaptive planning because they're easy to use with different levels of precision. The figure below (adapted from James Shore 's Beyond Story Cards article) illustrates this effect. userstorycone Originally uploaded by sjb140470 . Beyond the current release, user stories are typically epics that focus on broad or vague features. During release planning, the selected user stories may be split into smaller user stories that focus on narrower features. However, the purpose of release planning is to quickly establish a sense of how big a release might be. It's not necessary to split the user stories too far. You can tolerate a larger inaccuracy in their estimates because changes will occur over the period of the release. As the user stories approach the next iteration, they should be split further to focus on progressively smaller and more specific functionality. As the user stories become smaller, they become easier to estimate and their estimates will become less inaccurate. By the time the user stories are planned into the next iteration you want them to take between 1 and 2 days to complete, as a rule of thumb. During an iteration, it's difficult to start developing the software for user stories when you only know their names. Recall the conversation element of a user story. The developers and the customer need to collaborate and talk about the details of a user story at the latest responsible moment, i.e. when the details become important. Typically this collaboration to reveal the fine details of the user stories begins in the iteration planning meeting and facilitates a translation of the user stories into acceptance tests. As part of the collaboration, it's important that the developers understand the benefits of, and the motivation for each user story. Rachel Davies suggests that the developers use a simple checklist: Do we understand the value to the business that this user story provides? Do we know who the beneficiary of the user story is? Have we defined all the acceptance tests? Next post in this series: User stories part 3: Using spikes to help estimate user stories Previous posts in this series: User stories part 1: What is a user story and who writes them? References: [1] Mike Cohn 's Agile Estimating and Planning [2] Kent Beck and Martin Fowler 's Planning Extreme Programming
Comments: 2
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 .
