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

Re: The Scrum Release Plan Dilemma

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.