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

26854Re: The Scrum Release Plan Dilemma

Expand Messages
  • Tobias Mayer
    Feb 4, 2008
      Hi Petri,

      > Your comments sound like you feel there should be a "one size fits all" planning process.

      Well, no, but my original question was focused on one type of release planning that is taught on some CSM and Agile Planning courses, so in that sense, yes.   I was interested if anyone could give real world examples of when this technique added value.  I only had one (off-line) reply giving a real example.  I am convinced the method was used, however I am not convinced (yet) that it added value. 

      But more broadly, I do wonder whether the way release planning is approached in Agile is (as Mark/woynam speculates in an earlier response) a throwback to old project management "gotta figure it out" think.   It is time we began saying "I have no idea" more frequently, and with more gusto and abandon.   And then get on with building good software, right now.

      Your Now/Mañana suggestion is a good one, except that I would probably throw away all the cards not in the Now pile.  Any work with those cards probably adds no value.

      > If it's wasteful to you, stop doing it. :)
      > But don't fall into trap of thinking that it's wasteful to everyone

      I'm not sure it is a trap to ask the question:  "should we (or you) be doing this?"  or even to make the statement: "this seems like a waste of time... help me to see that it isn't."  In Agile we should question everything.  We forget, I think, how deeply bad practices and outdated ways of thinking are ingrained in our psyches.  Nothing should be sacred in the world of software process.  Nothing.


      --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo" <petri.heiramo@...> wrote:
      > --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" tobyanon@
      > wrote:
      > > 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.
      > Yours,
      > Petri Heiramo, CSP
      > SYSOPENDIGIA, Finland
    • Show all 17 messages in this topic