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

RE: [scrumdevelopment] Re: The Scrum Release Plan Dilemma

Expand Messages
  • Roy Morien
    On the face of it, there is a simple matter here. You have a Product Backlog listing the incomplete requirements identified so far, and an estimate of cost and
    Message 1 of 17 , Jan 31, 2008
    • 0 Attachment
      On the face of it, there is a simple matter here. You have a Product Backlog listing the incomplete requirements identified so far, and an estimate of cost and time to complete. Your client can, at any time, review that PB and draw a line under the lowest priority item that he 'must have' in the next release. That indicates, by virtue of some simple arithmetic, the next release date.
       
      All other things being equal, the client cannot demand a release date for all of those features, when the estimated time to complete exceeds that date. Something's gotta give. Either the release date gets extended, or the number of 'essential' features gets reduced, or ... and now cost to completion comes into play, extra resources are added to enable those features to be completed by that release date.
       
      Am I somehow missing the point here? Expressions such as 'getting blood out of a stone', and 'the programmers death march' do swirl around in my head somewhat.
       
      Regards,
      Roy Morien





      To: scrumdevelopment@yahoogroups.com
      From: bmwpapa@...
      Date: Fri, 1 Feb 2008 05:59:21 +0000
      Subject: [scrumdevelopment] Re: The Scrum Release Plan Dilemma

      I experienced the exact same thing as you describe. I tried to
      determine when the project would be ready for release, but couldn't
      reliably do so because of the constantly changing requirements (which
      we all know is to be expected), and because I did not know which
      features would deem the release "done". Asked, "When will the
      release
      be done?", I ask back, "What features are you expecting the release
      to
      include?"

      I feel like the closest I can get to addressing this problem would be
      to use Mike Cohn's "Alternate Release Burndown" to help project a
      release date range taking into account the trends of BOTH "work
      completed" AND "work added". As the "work added" tapers off, we'll
      know we're converging on a complete feature set. If it never tapers,
      then we'll never release, so the Product Owner is highly motivated to
      help taper it off.

      I am not an expert on this. I have the same questions as you. I
      posted my specific questions in the following message post, but to my
      disappointment, nobody has responded yet...

      ***
      *** SOMEBODY, PLEASE REVIEW THE FOLLOWING POST!
      ***

      ==> Re: Release Date Projection (Message #26670) <==

      b.

      --- In scrumdevelopment@ yahoogroups. com, "Tobias Mayer"
      <tobyanon@.. .> wrote:

      So here's my question to the community: how do you do effective
      release planning in the face of all this change? Chunking backlogs
      up
      according to velocity is all well and good, but essentially useless
      if
      all the stories are thrown away, or changed to the degree that re-
      estimation is necessary. Why even estimate beyond the next sprint or
      two? It concerns me at times that the focus on estimating whole
      backlogs and creating release plans is simply more waste, or worse
      (because of all the effort put into writing, comprehending and
      estimating the older stories) could potentially bind us into creating
      software that isn't really what the customer wants. The alternative
      is to have no release plan, or a purely date-driven plan with little
      knowledge of what will be in each release beyond some wild guesswork.




      Check our comprehensive Salary Centre Overpaid or Underpaid?
    • Mike Sutton
      I, same as you, have this dilemma. Some of the clients I have worked with and currently work with do not actually have a formal release plan. For some this is
      Message 2 of 17 , Feb 1, 2008
      • 0 Attachment
        I, same as you, have this dilemma. Some of the clients I have worked
        with and currently work with do not actually have a formal release
        plan. For some this is an issue, for others it doesn't matter.

        But I find that the answer to how much release planning you should do
        can be found within agile itself. Look as far forward as you
        reasonably can, but be prepared to revise it.

        Decide (loosely) on what a release is...
        'a release is 4 sprints of business value'; OR
        'a release is 100 story points'

        Split your backlog based on that decision... as the backlog gets
        estimated/revised what is in each release will also move. The closer
        you get to the release date/marker - the more accurately you can
        decide what is in it.

        In the only place I have tried this approach, we had acceptable
        success with the level of forecasting it gave us. We always knew when
        we would have a release (thats fixed date) and the scope is flexible -
        but we knew what was in by the 2nd to last sprint(2 week sprints) to
        the release. It also worked because the client had market determined
        periods when nothing could be done to production systems (6 weeks
        before and 2 weeks after Thanksgiving, Easter and Christmas periods).


        I am working with a team right now that announce they have releases
        (we are in Release 4) - but can't point me to anything that represents
        what release 4 is.

        Other experiences?

        cheers
        Mike
        csm.csp.cspo.certified.certifiable.

        --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" <tobyanon@...>
        wrote:
        >
        > A lot has been written about how a new Scrum team needs to begin with a
        > product backlog, and how the backlog, once estimated can be chunked into
        > possible sprints and thus a release plan can be created. I have even
        > taught this on CSM courses. In theory it is beautifully simple.
        > Trouble is, I have never once, with all the teams and companies I have
        > worked with, found a project that has a meaningful and complete backlog.
        > Usually the PO/stakeholders don't know what they want, or think they do
        > and spend a lot of time writing PRDs and other such nonsense, which are
        > then cast into stories, which are then estimated... which are then
        > thrown away after the first sprint or two because once the working
        > software is seen the stakeholders realized that what they thought they
        > want isn't actually what they want... and so on.
        >
        > For example, at each review meeting at my current place of work new
        > requests are made for features that immediately override previous
        > high-priority features. These are features that previously were simply
        > not thought of, and only emerged as a result of the stakeholders seeing
        > the working software. This is wonderful, and exactly how good software
        > should be created. But it plays havoc with any kind of release
        > planning.
        >
        > So here's my question to the community: how do you do effective release
        > planning in the face of all this change? Chunking backlogs up according
        > to velocity is all well and good, but essentially useless if all the
        > stories are thrown away, or changed to the degree that re-estimation is
        > necessary. Why even estimate beyond the next sprint or two? It
        > concerns me at times that the focus on estimating whole backlogs and
        > creating release plans is simply more waste, or worse (because of all
        > the effort put into writing, comprehending and estimating the older
        > stories) could potentially bind us into creating software that isn't
        > really what the customer wants. The alternative is to have no release
        > plan, or a purely date-driven plan with little knowledge of what will be
        > in each release beyond some wild guesswork.
        >
        > Am I missing something here? What are your experiences?
        >
        > Tobias
        > http://agilethinking.net <http://agilethinking.net>
        >
      • woynam
        I believe the Release Plan (RP) is one of the holdovers from traditional project management. In a pure Scrum enterprise, the Product Backlog would be the
        Message 3 of 17 , Feb 1, 2008
        • 0 Attachment
          I believe the Release Plan (RP) is one of the holdovers from
          "traditional" project management.

          In a "pure" Scrum enterprise, the Product Backlog would be the only
          artifact used to track features. The team would take the top N high
          priority features, and turn them into working software every
          iteration. Ideally, we'd like to deploy the software at the end of
          every iteration, and if we could, our "Release Plan" would simply be
          the Product Backlog. No need for a separate RP.

          However, two things generally interfere with this idealized model.
          First, for many of us, features have to be deployed together. There
          are typically minimum sets of features that are required to go live.
          In a trading system, you can't support "Enter Order" if you don't have
          a "Cancel Order", and a "Cancel/Replace Order" function. Thus, the
          release plan provides the general roadmap as to when a business can
          expect a deployable set of features.

          Second, I believe many organizations are not ready to abandon the
          project-centric view of the world, especially from the accounting
          standpoint. We still plan, budget, and execute at the project level,
          even though we interleave multiple projects into a multi-team
          development environment. A project's feature set may be developed by a
          single team, or may be split across multiple teams. A team may work on
          a single project's features, or may work on features that cross-cut
          multiple projects. Since the product backlog contains features from
          multiple projects, it doesn't give the business a good view as to when
          a specific project may be ready to go live. Thus, the RP identifies
          when each of the project's features will be developed.

          We have approximately 25 projects under development at any given time,
          with roughly 20 teams working in parallel. We also have another 50 or
          so projects in the backlog/portfolio. Each project in the backlog is
          represented by a project charter, so there's not a lot invested in it
          until it's ready to start. When a project is ready to start, we
          conduct an "Iteration 0" pre-planning sprint, ranging in length from a
          day to a few weeks, depending on the size of the project, in which we
          identify the features (user stories), estimate the features, and
          develop the release plan. The RP is presented at the kickoff for
          Iteration 1, and then the focus narrows to the features that will be
          developed during the first iteration.

          I'm currently working on one of the largest projects we've tackled in
          a long time, the migration of our main application from our mainframe
          to our new trading platform. The original release plan called for 13
          iterations with 4 rollouts. Of course, we had to take a stab at
          estimating the features to come up with the 13 iterations. The process
          took roughly a week, and we wound up with approximately 100 features.

          We're now in our 26th iteration, with 32 planned. We have 3 teams
          working in parallel, with ~30 developers. Obviously, we discovered a
          few missing features along the way :-), and re-estimated many others.
          However, we also took this as an opportunity to reengineer a good
          chunk of the business, as you don't often get a chance to migrate off
          a legacy platform, and ditch a lot of accumulated gunk. As expected,
          we've been continuously planning, with the RP updated along the way.
          The RP has been valuable in that it provides the business a snapshot
          as to when they might expect a "fully" functional system. More
          importantly, it provides the basis for doing what-if scenarios with
          the feature set. As the business pushes to get the project completed,
          we're constantly reviewing features to see if they can be deferred
          until a later release, eliminated altogether, or replaced with a
          different feature that satisfies the core business requirement.

          Lastly, I should add that the estimation of features does not take all
          that much time. When a feature is first added to the release plan, it
          doesn't take more than a few minutes to go around the room and get
          everyone's input.

          Mark


          --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" <tobyanon@...>
          wrote:
          >
          > Hi Roy,
          >
          > If you had read further down the post you will see I said "This
          > [changing requirements] is wonderful, and exactly how good software
          > should be created..." Of course requirements change, and indeed they
          > should. 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.
          >
          > 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 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.
          >
          > I hope this helps make my request clearer.
          >
          > Tobias
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@>
          > wrote:
          > >
          > > It seems to me, from your words, Tobias, that there is a fundamental
          > contradiction here, between the general principles of agile development,
          > and your discussion about having a project having a meaningful and
          > complete backlog at the start. This almost seems like a slight variation
          > of the 'BDUF' approach.
          > >
          > > At all times, I thought, the Product Backlog was the best information
          > available AT THAT TIME about system requirements. At all times there was
          > an implication that the Product Backlog was up for review and
          > adaptation. Stories (or whatever was being recorded) could be added,
          > taken away, modified, re-prioritised, upgraded, downgraded etc. So at
          > any given moment it is indeed a meaningful and complete backlog, given
          > the current state of knowledge.
          > >
          > > So, at the start of the project, a useable and implementable backlog
          > can be created very quickly, very soon, and be a good foundation for
          > planning the next sprint. Given my experience with predominantly
          > database systems development, that can mean after the identification of
          > the first Entity.
          > >
          > > However, I have never been in a situation where so little was known or
          > understood about the system, in general terms, that the development team
          > was starting with a totally sparse backlog. Many requirements are almost
          > immediately evident in most situations, but obviously need to be
          > 'fleshed out' as the development activity proceeds. This is just the
          > concept of 'just in time' requirements determination.
          > >
          > > I have certainly found that having significant and proven standards
          > helps a lot ... GUI interface design standards, code standards,
          > documentation standards, standard class and function libraries etc.
          > >
          > > Am I being simplistic here? I admit that I have never worked on a
          > multi-year, 1000 developer system project, and my experience is mainly
          > business systems development.
          > >
          > > Regards,
          > > Roy Morien
          > >
          > >
          > > To: scrumdevelopment@: tobyanon@: Thu, 31 Jan 2008 04:37:25
          > +0000Subject: [scrumdevelopment] The Scrum Release Plan Dilemma
          > >
          > >
          > >
          > >
          > > A lot has been written about how a new Scrum team needs to begin with
          > a product backlog, and how the backlog, once estimated can be chunked
          > into possible sprints and thus a release plan can be created. I have
          > even taught this on CSM courses. In theory it is beautifully simple.
          > Trouble is, I have never once, with all the teams and companies I have
          > worked with, found a project that has a meaningful and complete backlog.
          > Usually the PO/stakeholders don't know what they want, or think they do
          > and spend a lot of time writing PRDs and other such nonsense, which are
          > then cast into stories, which are then estimated... which are then
          > thrown away after the first sprint or two because once the working
          > software is seen the stakeholders realized that what they thought they
          > want isn't actually what they want... and so on. For example, at each
          > review meeting at my current place of work new requests are made for
          > features that immediately override previous high-priority features.
          > These are features that previously were simply not thought of, and only
          > emerged as a result of the stakeholders seeing the working software.
          > This is wonderful, and exactly how good software should be created. But
          > it plays havoc with any kind of release planning.So here's my question
          > to the community: how do you do effective release planning in the face
          > of all this change? Chunking backlogs up according to velocity is all
          > well and good, but essentially useless if all the stories are thrown
          > away, or changed to the degree that re-estimation is necessary. Why
          > even estimate beyond the next sprint or two? It concerns me at times
          > that the focus on estimating whole backlogs and creating release plans
          > is simply more waste, or worse (because of all the effort put into
          > writing, comprehending and estimating the older stories) could
          > potentially bind us into creating software that isn't really what the
          > customer wants. The alternative is to have no release plan, or a
          > purely date-driven plan with little knowledge of what will be in each
          > release beyond some wild guesswork.Am I missing something here? What
          > are your experiences?Tobiashttp://agilethinking.net
          > >
          > >
          > >
        • Petri Heiramo
          ... 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
          Message 4 of 17 , Feb 3, 2008
          • 0 Attachment
            --- 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
          • aacockburn
            ... You semi answer the question ... you have to move to a date-driven plan. The purpose of each release planning exercise now becomes: With what we NOW know,
            Message 5 of 17 , Feb 4, 2008
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
              <tobyanon@...> wrote:
              >
              > I have never found a project that has a meaningful
              > and complete backlog.
              > These are features that previously were simply not
              > thought of, and only emerged as a result of the
              > stakeholders seeing the working software.
              > It plays havoc with any kind of release planning.
              > How do you do effective release planning in the
              > face of all this change?
              > The alternative is to have no release plan, or a
              > purely date-driven plan with little knowledge of what
              > will be in each release beyond some wild guesswork.

              You semi answer the question ... you have to move to a
              date-driven plan.

              The purpose of each release planning exercise now becomes:

              "With what we NOW know, what will the most useful system
              we can create look like on THAT date?"

              Personally, I think that is a valuable exercise. It allows
              also for the sponsors to reply with,

              "What would it look like if we changed the date?"

              Personally, I think that you should always have a coarse-
              grained statement of time and content goal (and everyone
              on the team should know it). If you are missing that, then
              it is hard for everyone on the team (including the sponsors)
              to pull in the same direction.

              Does this help you out at all?

              Alistair
            • Tobias Mayer
              Hi Petri, ... 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
              Message 6 of 17 , Feb 4, 2008
              • 0 Attachment
                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.

                Tobias


                --- 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
                >
              • Tobias Mayer
                Hi Alistair, ... look like on THAT date? ... Yes, this is useful. It is simple and elegant. I think it is probably all that is needed in terms of release
                Message 7 of 17 , Feb 4, 2008
                • 0 Attachment
                  Hi Alistair,

                  > "With what we NOW know, what will the most useful system we can create look like on THAT date?"
                  > ... "What would it look like if we changed the date?"


                  Yes, this is useful. It is simple and elegant.  I think it is probably all that is needed in terms of "release planning".  It has a focus on establishing and expressing vision, without counting points or stories or anything else.

                  Vision in the Agile process is vital for success, whether it is a vision statement for the whole project, for a particular date-driven release or a single sprint (i.e. a sprint goal).  Without vision we may as well all go find another job because the one we are in is gonna suck ;-)

                  Tobias



                  --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...> wrote:
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer"
                  > tobyanon@ wrote:
                  > >
                  > > I have never found a project that has a meaningful
                  > > and complete backlog.
                  > > These are features that previously were simply not
                  > > thought of, and only emerged as a result of the
                  > > stakeholders seeing the working software.
                  > > It plays havoc with any kind of release planning.
                  > > How do you do effective release planning in the
                  > > face of all this change?
                  > > The alternative is to have no release plan, or a
                  > > purely date-driven plan with little knowledge of what
                  > > will be in each release beyond some wild guesswork.
                  >
                  > You semi answer the question ... you have to move to a
                  > date-driven plan.
                  >
                  > The purpose of each release planning exercise now becomes:
                  >
                  > "With what we NOW know, what will the most useful system
                  > we can create look like on THAT date?"
                  >
                  > Personally, I think that is a valuable exercise. It allows
                  > also for the sponsors to reply with,
                  >
                  > "What would it look like if we changed the date?"
                  >
                  > Personally, I think that you should always have a coarse-
                  > grained statement of time and content goal (and everyone
                  > on the team should know it). If you are missing that, then
                  > it is hard for everyone on the team (including the sponsors)
                  > to pull in the same direction.
                  >
                  > Does this help you out at all?
                  >
                  > Alistair
                  >
                • Petri Heiramo
                  Hi Tobias, ... release ... in ... I guess you can guess that I would focus on your words one type of release planning :). ... line) ... That is a good
                  Message 8 of 17 , Feb 5, 2008
                  • 0 Attachment
                    Hi Tobias,


                    > > 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 guess you can guess that I would focus on your words "one type of
                    release planning" :).

                    > 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.

                    That is a good question. I haven't seen a practical "by the book"
                    example in our projects, either, but I don't claim intimate knowledge
                    of all the projects. I know that some projects need to map their
                    estimates (or even certain commitments) to biweekly releases in some
                    projects. The plans may change, but they need to convey their current
                    estimates to other teams in the larger ecosystem to manage
                    dependencies between teams. The system is very similar to the book
                    case, although the tools and the terminology they use doesn't match.

                    > 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.

                    "I have no idea" should be used sparingly, because it's rarely the
                    case. However, we should induce the correct kind of thinking ("this
                    is just an estimate, we'll see what turns out and how things will
                    change") in the people making the broader decisions. They need to
                    understand that all they are seeing are educated guesses.

                    Obviously, there are different kind of project environments. I know
                    some very research oriented projects that have troubles making two-
                    week plans; their plans change too much within one week as they learn
                    new things. Some other projects can speculate things several months
                    ahead. But regardless of the visibility, anything but "today" is not
                    a commitment in Agile.

                    > 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.

                    I'd just put them aside and bring them to the next meeting,
                    saying "you had these ideas last time, let's do another mañana
                    analysis and see what's important now." There are often valuable
                    ideas in those cards, but they were just not relevant the last time
                    (for example, features which build on other features are not relevant
                    until the other features are built).

                    > > 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.

                    Nothing is sacred, but there are some good ideas that we might still
                    find useful from the past. The questions you ask are very good to be
                    made, but the answer is not always the same. But other than that, I
                    agree with you wholeheartedly.


                    Yours,


                    Petri Heiramo, CSP
                    SYSOPENDIGIA, Finland
                  • Tobias Mayer
                    Hi Petri ... case. Haha. Yes, you are right. bad choice of words. We always have ideas (not necessarily good ones). Perhaps it is simpler and more honest
                    Message 9 of 17 , Feb 5, 2008
                    • 0 Attachment
                      Hi Petri

                      > "I have no idea" should be used sparingly, because it's rarely the case.

                      Haha.  Yes, you are right.  bad choice of words.  We always have ideas (not necessarily good ones).  Perhaps it is simpler and more honest to simply say "I don't know".

                      Thanks for your thoughts on this topic.

                      Tobias


                      --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo" <petri.heiramo@...> wrote:
                      >
                      > Hi Tobias,
                      >
                      >
                      > > > 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 guess you can guess that I would focus on your words "one type of
                      > release planning" :).
                      >
                      > > 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.
                      >
                      > That is a good question. I haven't seen a practical "by the book"
                      > example in our projects, either, but I don't claim intimate knowledge
                      > of all the projects. I know that some projects need to map their
                      > estimates (or even certain commitments) to biweekly releases in some
                      > projects. The plans may change, but they need to convey their current
                      > estimates to other teams in the larger ecosystem to manage
                      > dependencies between teams. The system is very similar to the book
                      > case, although the tools and the terminology they use doesn't match.
                      >
                      > > 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.
                      >
                      > "I have no idea" should be used sparingly, because it's rarely the
                      > case. However, we should induce the correct kind of thinking ("this
                      > is just an estimate, we'll see what turns out and how things will
                      > change") in the people making the broader decisions. They need to
                      > understand that all they are seeing are educated guesses.
                      >
                      > Obviously, there are different kind of project environments. I know
                      > some very research oriented projects that have troubles making two-
                      > week plans; their plans change too much within one week as they learn
                      > new things. Some other projects can speculate things several months
                      > ahead. But regardless of the visibility, anything but "today" is not
                      > a commitment in Agile.
                      >
                      > > 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.
                      >
                      > I'd just put them aside and bring them to the next meeting,
                      > saying "you had these ideas last time, let's do another mañana
                      > analysis and see what's important now." There are often valuable
                      > ideas in those cards, but they were just not relevant the last time
                      > (for example, features which build on other features are not relevant
                      > until the other features are built).
                      >
                      > > > 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.
                      >
                      > Nothing is sacred, but there are some good ideas that we might still
                      > find useful from the past. The questions you ask are very good to be
                      > made, but the answer is not always the same. But other than that, I
                      > agree with you wholeheartedly.
                      >
                      >
                      > Yours,
                      >
                      >
                      > Petri Heiramo, CSP
                      > SYSOPENDIGIA, Finland
                      >
                    • Michael Maham
                      Tobias, this is a very good topic. Another complicating circumstance in some environments is when the development is not internal or for a single customer.
                      Message 10 of 17 , Feb 5, 2008
                      • 0 Attachment
                        Tobias, this is a very good topic.  Another complicating circumstance in some environments is when the development is not internal or for a single customer.  In these settings, the release plan has value for the other parts of the organization (marketing, sales, services, support, etc) as they know what they need by when, for example, services people will need skill around Platform X since it will be supported in Release Y.  Not all of those groups "signed up for Agile" but are still having to adapt to the new ways the development groups are delivering.

                        michael

                        On Tue, Feb 5, 2008 at 7:53 AM, Tobias Mayer <tobyanon@...> wrote:

                        Hi Petri



                        > "I have no idea" should be used sparingly, because it's rarely the case.

                        Haha.  Yes, you are right.  bad choice of words.  We always have ideas (not necessarily good ones).  Perhaps it is simpler and more honest to simply say "I don't know".

                        Thanks for your thoughts on this topic.

                        Tobias


                        --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo" <petri.heiramo@...> wrote:
                        >
                        > Hi Tobias,
                        >
                        >
                        > > > 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 guess you can guess that I would focus on your words "one type of
                        > release planning" :).
                        >
                        > > 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.
                        >
                        > That is a good question. I haven't seen a practical "by the book"
                        > example in our projects, either, but I don't claim intimate knowledge
                        > of all the projects. I know that some projects need to map their
                        > estimates (or even certain commitments) to biweekly releases in some
                        > projects. The plans may change, but they need to convey their current
                        > estimates to other teams in the larger ecosystem to manage
                        > dependencies between teams. The system is very similar to the book
                        > case, although the tools and the terminology they use doesn't match.
                        >
                        > > 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.
                        >
                        > "I have no idea" should be used sparingly, because it's rarely the
                        > case. However, we should induce the correct kind of thinking ("this
                        > is just an estimate, we'll see what turns out and how things will
                        > change") in the people making the broader decisions. They need to
                        > understand that all they are seeing are educated guesses.
                        >
                        > Obviously, there are different kind of project environments. I know
                        > some very research oriented projects that have troubles making two-
                        > week plans; their plans change too much within one week as they learn
                        > new things. Some other projects can speculate things several months
                        > ahead. But regardless of the visibility, anything but "today" is not
                        > a commitment in Agile.
                        >
                        > > 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.
                        >
                        > I'd just put them aside and bring them to the next meeting,
                        > saying "you had these ideas last time, let's do another mañana
                        > analysis and see what's important now." There are often valuable
                        > ideas in those cards, but they were just not relevant the last time
                        > (for example, features which build on other features are not relevant
                        > until the other features are built).
                        >
                        > > > 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.
                        >
                        > Nothing is sacred, but there are some good ideas that we might still
                        > find useful from the past. The questions you ask are very good to be
                        > made, but the answer is not always the same. But other than that, I
                        > agree with you wholeheartedly.
                        >
                        >
                        > Yours,
                        >
                        >
                        > Petri Heiramo, CSP
                        > SYSOPENDIGIA, Finland
                        >

                      • mpkirby
                        ... We create a backlog of epic s with short descriptions. Each epic is prioritized by the product owner, and then each of the teams will bid on how much
                        Message 11 of 17 , Feb 6, 2008
                        • 0 Attachment
                          aacockburn wrote:
                          >
                          > Personally, I think that you should always have a coarse-
                          > grained statement of time and content goal (and everyone
                          > on the team should know it). If you are missing that, then
                          > it is hard for everyone on the team (including the sponsors)
                          > to pull in the same direction.
                          >
                          > Does this help you out at all?


                          We create a backlog of "epic's" with short descriptions. Each epic is
                          prioritized by the product owner, and then each of the teams will "bid"
                          on how much effort it would take to implement the feature. We use a
                          generic "complexity point" for each team.

                          Each release is usually around 12 weeks (with a number of weeks
                          afterwards for hardware/software wring-out, as well as other subsystems
                          (the physicists) getting a chance to validate algorithms).

                          After each team is "full" the scrum teams will work with the product
                          owner (in this case we use product-owner proxies into a systems
                          engineering organization because of the size of group). to break the
                          epics into reasonable sized chunks. Most scrums use a two week
                          iteration. I suppose if you squint, you could say we have a 1 week task
                          cycle on top of that.

                          The stories get planned (allocated to iterations), until the teams
                          basically considers themselves full. At this point we might prioritize
                          some of the lower priority stories out of the release all-together. We
                          write customer acceptance tests for the stories for the upcoming
                          iteration, and break them down into tasks ( we estimate tasks and
                          stories in hours, not story points).

                          During the development the product owner and team work together to
                          prioritize and adjust the stories associated with the epic based on the
                          demo's at the end of each of the two week iterations. The general rule
                          is that we can change the scope and mission of the epic (for future
                          iterations) as long as we don't exceed the original allotment of effort
                          for the epic.

                          So, for example, if we estimated an epic as a "High" (approximately 600
                          hours), we would allow changes to stories and additions and deletions so
                          long as we don't exceed 600 hours. If we exceed 600 hours, we have to
                          go back through the organizational balancing process to get more work
                          tokens. (typically dropping something off our release plan, not just the
                          scrum team's backlog.).

                          I hope this (rather short and terse) description of what we do was
                          helpful. For larger organizations the biggest problem I have found is
                          maintaining the sense of commitments. Working software every two weeks
                          helps, but it isn't a substitute for a little bit of forward thinking on
                          what you plan to deliver. This is particularly true when there are
                          other groups that depend on your deliveries to make the product (e.g.
                          hard tooling in manufacturing, mechanical and electrical design teams, etc).

                          I suppose the flip answer is that they should all be part of the scrum
                          team, but it gets a bit impractical. The skills are too diverse, and
                          the teams would be too large.

                          Mike
                        • barvybe
                          Hi Michael, This is largely our situation. Both our customers and the majority of our dev team are external to the company. Internally we have product
                          Message 12 of 17 , Feb 6, 2008
                          • 0 Attachment
                            Hi Michael,
                            This is largely our situation. Both our customers and the majority of
                            our dev team are external to the company. Internally we have product
                            managers, a scrum master, an agile coach (me), and a lead architect.
                            It's a difficult situation to manage with Agile for obvious reasons.

                            At the moment, our marketing dept. doesn't have a lot of faith in
                            Agile and I'm mostly managing him in terms of keeping him from
                            imposing full requirements. He wants full release planning (really
                            waterfall planning), and we're just not budging on that. At the same
                            time, he is very reluctant to engage his product managers on a
                            consistent basis with the team to do our "just in time planning",
                            acceptance test criteria, etc. I happen to be in position as one of
                            the company's partners to ultimately impose my will on this situation
                            but am working instead to turn him around.

                            We do have a backlog and manage it much as others have been described:
                            - items come in as request stories which are then either placed in the
                            "future" bin, rejected, or moved to active backlog.
                            - the backlog for each project is re-prioritized weekly to account for
                            both new requests and things dropping out
                            - the team does "poker planning" level estimates on everything in the
                            active backlog that doesn't already have a story point estimate about
                            a week before the iteration would begin so that the above priority
                            process can take effort into account (particularly since effort is an
                            hourly outsourced direct cost in many cases).

                            The business reasons for release planning and detailed estimates prior
                            to dev work starting for us are largely for budget and sales planning
                            as has been suggested elsewhere:
                            - work = hours = $$ against a product managers budget for the year
                            - client (customer) requests, trade shows, and sales campaigns impose
                            a calendar of minimum feature set releases.

                            Our struggles right now lie in 3 areas that we are working through:

                            1. clear business requirements: with outsource dev (on 12 hour time
                            shift) we cannot rely on the conversational working out of details.
                            Instead, we require a good product charter, actor descriptions, and
                            use case scenarios (really epic stories) from our product managers.
                            We then break the epics into user stories prior to or during poker
                            planning and only do so for the highest priority feature epics.
                            ISSUE: our product managers don't like writing those business docs
                            and our marketing director find their continual involvement in weekly
                            discussions to be disruptive to how he likes to work (3 months of
                            planning and handoff followed by 3 months of market research on the
                            next big opportunity)
                            - my proposed solution to him is to have two types of product
                            managers: line managers working with the production team daily and
                            market sizing and business case product managers who do the initial
                            visioning work and get executive buy in prior to handing off to the
                            line product manager.

                            2. accounting: since we pay hourly for dev resources and need to
                            account for each hour against product, project and often client
                            opportunities we end up needed detailed hour tracking --> detailed
                            task lists, etc.
                            - my proposed solution to this is to bring more of our dev in house
                            and we're working toward that end.

                            3. insufficient ownership of acceptance testing by the business side.
                            My opinion is that test cases / acceptance criteria must be written
                            by someone in house - a business focused employee who will look at the
                            product from the customer and end user's perspective. Marketing would
                            like this to be a technology function instead.
                            - my proposed solution is that Product Managers will write brief
                            acceptance criteria. Then, our Product Support team will grow to
                            include test case writing that will encompass the acceptance criteria
                            and add functional test cases. Test cases will then be passed to a
                            technology resource to write test scripts, automation, etc.

                            ________________

                            The above got a bit off topic, but ultimately we'll end up with a date
                            driven release cycle with flexibility on feature set and - if the
                            product manager wishes to allocate more budget - flexibility on
                            resources. From my standpoint as an owner, understanding the actual
                            costs of each features initial dev and maintenance dev is critical to
                            assessing the accuracy of the marketing teams P&L estimates and
                            responsibility.

                            IF we were a startup or budget wasn't really an issue, then I would
                            throw any real plan out and just have the team focus on building the
                            initial product for launch by "locking them in a room" together....

                            - Pete

                            --- In scrumdevelopment@yahoogroups.com, "Michael Maham"
                            <michael.maham@...> wrote:
                            >
                            > Tobias, this is a very good topic. Another complicating circumstance in
                            > some environments is when the development is not internal or for a
                            single
                            > customer. In these settings, the release plan has value for the
                            other parts
                            > of the organization (marketing, sales, services, support, etc) as
                            they know
                            > what they need by when, for example, services people will need skill
                            around
                            > Platform X since it will be supported in Release Y. Not all of
                            those groups
                            > "signed up for Agile" but are still having to adapt to the new ways the
                            > development groups are delivering.
                            >
                            > michael
                            >
                            > On Tue, Feb 5, 2008 at 7:53 AM, Tobias Mayer <tobyanon@...> wrote:
                            >
                            > > Hi Petri
                            > >
                            > >
                            > > *> "I have no idea" should be used sparingly, because it's rarely the
                            > > case.
                            > >
                            > > *
                            > > Haha. Yes, you are right. bad choice of words. We always have ideas
                            > > (not necessarily good ones). Perhaps it is simpler and more honest to
                            > > simply say "I don't know".
                            > >
                            > > Thanks for your thoughts on this topic.
                            > >
                            > > Tobias
                            > >
                            > >
                            > > --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
                            <petri.heiramo@>
                            > > wrote:
                            > > >
                            > > > Hi Tobias,
                            > > >
                            > > >
                            > > > > > 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 guess you can guess that I would focus on your words "one type of
                            > > > release planning" :).
                            > > >
                            > > > > 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.
                            > > >
                            > > > That is a good question. I haven't seen a practical "by the book"
                            > > > example in our projects, either, but I don't claim intimate
                            knowledge
                            > > > of all the projects. I know that some projects need to map their
                            > > > estimates (or even certain commitments) to biweekly releases in some
                            > > > projects. The plans may change, but they need to convey their
                            current
                            > > > estimates to other teams in the larger ecosystem to manage
                            > > > dependencies between teams. The system is very similar to the book
                            > > > case, although the tools and the terminology they use doesn't match.
                            > > >
                            > > > > 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.
                            > > >
                            > > > "I have no idea" should be used sparingly, because it's rarely the
                            > > > case. However, we should induce the correct kind of thinking ("this
                            > > > is just an estimate, we'll see what turns out and how things will
                            > > > change") in the people making the broader decisions. They need to
                            > > > understand that all they are seeing are educated guesses.
                            > > >
                            > > > Obviously, there are different kind of project environments. I know
                            > > > some very research oriented projects that have troubles making two-
                            > > > week plans; their plans change too much within one week as they
                            learn
                            > > > new things. Some other projects can speculate things several months
                            > > > ahead. But regardless of the visibility, anything but "today" is not
                            > > > a commitment in Agile.
                            > > >
                            > > > > 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.
                            > > >
                            > > > I'd just put them aside and bring them to the next meeting,
                            > > > saying "you had these ideas last time, let's do another mañana
                            > > > analysis and see what's important now." There are often valuable
                            > > > ideas in those cards, but they were just not relevant the last time
                            > > > (for example, features which build on other features are not
                            relevant
                            > > > until the other features are built).
                            > > >
                            > > > > > 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.
                            > > >
                            > > > Nothing is sacred, but there are some good ideas that we might still
                            > > > find useful from the past. The questions you ask are very good to be
                            > > > made, but the answer is not always the same. But other than that, I
                            > > > agree with you wholeheartedly.
                            > > >
                            > > >
                            > > > Yours,
                            > > >
                            > > >
                            > > > Petri Heiramo, CSP
                            > > > SYSOPENDIGIA, Finland
                            > > >
                            > >
                            > >
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.