Loading ...
Sorry, an error occurred while loading the content.

26820Re: The Scrum Release Plan Dilemma

Expand Messages
  • Petri Heiramo
    Feb 3, 2008
      --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" <tobyanon@...>
      > The point I am making is when they change so radically (and my
      > experience is that this happens more often than not) it makes a mockery
      > of release plans, so why take time to do them in the first place? It is
      > almost as if we are pretending we know more than we do, that in fact the
      > current state of the backlog is taken to be a finished plan.

      Your comments sound like you feel there should be a "one size fits
      all" planning process. In my understanding, there isn't one. Your case
      sounds like a situation where forward planning makes little sense.
      Thus, I wouldn't do it, if the customer and the stakeholders can live
      with it. I would naturally keep discussing the future options and how
      the product backlog should develop, but wouldn't really make feature
      level plans for the future. Maybe a rough roadmap for some fundamental
      key features, but nothing that couldn't be changed at any moment.

      If the customer and stakeholders require you to do planning, you might
      want to explain them the situation and seek out a less-plan-driven
      approach. But it might also be that they need to do those plans, in
      order to work efficiently at their level, regardless of the need to
      change them frequently.

      Not every project has the same amount of volatility you have.
      Therefore the release planning might make much more sense in other
      projects, and could therefore be a good tool there.

      > A lot of time goes into understanding and estimating each story, and I
      > wonder about the value of this when the expected implementation of a
      > story is not imminent.

      I liked one idea I heard regarding this problem. In one word, it
      becomes down to prioritizing. As part of the planning session, ask the
      team and customer (or whoever are in the meeting) to split the stories
      into two piles:
      - Now
      - Mañana ("tomorrow" in Spanish, as far as I know)

      The "Now" pile gets every story that is relevant _right_now_ (or
      during the next sprint), in some way. Relevance could be that the team
      has to do something about it or that they need to examine and study it
      in order to be able act correctly in current situation.

      The "Mañana" pile gets every other card.

      After that, the Mañana pile gets puts aside and all attention is
      focused on the Now items. This simple methods cuts out a lot of stuff
      that isn't relevant for discussion at this very moment. Depending on
      the situation and the project case, you can use the tool differently,
      or even several times in row. For example, first define Mañana as
      anything that isn't relevant in the next three months (for example,
      when planning a year long project), then do another round and set the
      threshold to the next two sprints. Once you have the piles, you can
      apply different planning techniques to them. For example, do nothing
      on the first Mañana pile, give rough quick estimates on the second
      pile, and only do a more detailed estimation for the second Now pile.

      > I understand in theory that release planning is good, and the Agile
      > approach makes a great deal of sense... it's just that I have rarely
      > been able to do it and have it be useful on projects that are being
      > defined as they develop. Hence my request for real world experience of
      > effective release planning in the face of radical change.

      If it's wasteful to you, stop doing it. :)

      But don't fall into trap of thinking that it's wasteful to everyone
      else, too.


      Petri Heiramo, CSP
      SYSOPENDIGIA, Finland
    • Show all 17 messages in this topic