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
2 Comments
This is a very nice series of posts. One small problem: in the diagram, the direction of the cone is backwards. It should start broad and become narrow as time passes. The original diagram from which this is adapted has it right. Good information overall, though.
Yeah I know. I chose to approach it from the perspective of looking into the future: Here and now (on the left), looking forward in time (to the right) the detail of user stories is more ambiguous.