Agile 2009: Advances in Release Planning

• August 24, 2009• 2 min•

planningStopped by to see Jim Highsmith’s session to pick up a few good ideas.  Not surprisingly, there was a good deal of focus on release planning, some focus on value and discussing features along a continuum.  In many traditionally managed products, there is an emphasis on the up-front planning, or as he termed it “wish-based planning”.  During this inception stage, management spends a lot of time trying to answer the following questions with a high degree of precision:

  1. What are the main dependencies in this product?
  2. What sort of risks do we expect?  How do we mitigate them?
  3. Do we have enough resources?  How will they be distributed?
  4. What sort of value will this product provide?
  5. How much will it cost us?
  6. When will the product be delivered?

Of course, Agile products want to answer these questions as well and we often figure this out during release planning.  We want to know early on if the product is feasible and does it align with out goals and strategic objectives.  Where Agile teams differ is we recognize the release plan is only a guide and is flexible.  Another key difference is that an Agile team will estimate on the user story level, not at the task level.  We perform the task estimation Just-In-Time.  The creation of the release plan is really a conversation meant to answer all these questions.  Finally, while most products benefit from a release plan, there are cases of highly experimental work where an iteration-by-iteration approach is valuable.

Another useful concept discussed at the session was the continuum of completeness for features.  Instead of assuming all features have the same level of completeness, have conversations about what needs to be delivered using this model:

    simplest -> basic -> nominal -> extensive

With this framework in mind, we now can have discussion around trade-offs and partial delivery.  Why develop an extensive solution when the market leaders are only providing nominal?  Is that are market differentiator or just engineering gold-plating?  Or maybe we can only afford a basic implementation?  At least we can make these decisions at the product level instead of the engineers making these decisions for us.

Finally, Jim made a big point about understanding the value for a feature.  From his experience, even a fuzzy number around the value for a feature is acceptable if detailed data is unavailable..  In his words:

“If the product group does not have the time to calculate the value, then the programmers do not have time to estimate the cost.”