26820Re: The Scrum Release Plan Dilemma
- Feb 3, 2008--- In firstname.lastname@example.org, "Tobias Mayer" <tobyanon@...>
> The point I am making is when they change so radically (and myYour comments sound like you feel there should be a "one size fits
> 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.
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 II liked one idea I heard regarding this problem. In one word, it
> wonder about the value of this when the expected implementation of a
> story is not imminent.
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:
- 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 AgileIf it's wasteful to you, stop doing it. :)
> 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.
But don't fall into trap of thinking that it's wasteful to everyone
Petri Heiramo, CSP
- << Previous post in topic Next post in topic >>