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

Nesting weekly iterations within monthly sprints

Expand Messages
  • gackle@shaw.ca
    My team have been using Scrum successfully. We now wish to experiment with shorter iterations, and would like some advice. A few months ago there was a thread
    Message 1 of 14 , Nov 25, 2003
    • 0 Attachment
      My team have been using Scrum successfully. We now wish to experiment with shorter iterations, and would like some advice.

      A few months ago there was a thread on this topic, "Sprint.length < 30," which I'll summarize here. Some people felt that 30 day iterations are optimal for delivering increments of functionality. Others questioned this and pointed out that XP teams routinely use weekly iterations. Several posts argued that the optimal length depends on the personality of the team.

      I want to ask about this from a different angle: if a Scrum team does want to experiment with shorter iterations, how might it best proceed? We want to experiment but we don't want to mess with the synergy of the core Scrum practices.

      For us, a monthly cycle is natural for interacting with the "external world". We're a small team in a large company. Our product owner is very much part of the team but our upper managers are not. Meeting with them for a review every month, and being shielded from interference in the meantime, is just right for both sides.

      Where the monthly cycle is less natural is in our "internal world" of planning and completing tasks. Our monthly pattern goes like this: "Meander, meander, meander, realize there isn't much time left, freak out, get intense, ok we're done. Repeat monthly."

      We seem to be running up against a basic block: psychologically, a month is "a long time". We're like the primitive tribe whose counting system goes "1, 2, 3, many." A month is on the "many" side. The brain doesn't seem to take it seriously enough. Only when the deadline (the sprint review) moves within the 'serious' range does reality kick in. At that point focus seems to occur spontaneously. But we're left regretting our lack of focus earlier in the sprint.

      There's another aspect too. The detailed monthly planning feels onerous and is taking way too long. We're planning tasks that none of us may touch for another 3 weeks. It reminds me of how I used to feel doing up-front design for code I wasn't going to be writing any time soon. It feels burdensome. Also, for us, it's pseudo-accurate since we're trying to figure out too much in advance.

      We want to experiment with nesting shorter cycles within the month. Our hope is that since a week is psychologically "not much time", we might spend more of each month on focused, productive work.

      Here are the questions we came up with:

      1. If we do detailed task planning for a week at a time, and continue to do coarse-grained planning in the overall product backlog, would we still be doing any monthly planning, and if so what?

      2. Given that we're working in weekly increments, can our product owner reprioritize what he wants done on a week-by-week basis, instead of month by month? Keep in mind that in our case, the product owner is "one of us". The external stakeholders would still be steering us on a monthly basis.

      3. The sprint review at the end of the month is a big milestone that we take seriously and gives us something to shoot for. What sort of mini-milestone can we put in place to make the end-of-the-week deadline seem real?

      4. We don't want to break Scrum by altering its core practices. Do we risk doing that here, and if so how?

      Please advise!

      - Daniel
    • Deb
      ... I find that the Sprint Backlog is the answer to the above pattern. From day 1 you can see your goal, and from day 2 you can see if you re aiming for it or
      Message 2 of 14 , Nov 25, 2003
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, gackle@s... wrote:
        >"Meander, meander, meander, realize there isn't much time left,
        > freak out, get intense, ok we're done. Repeat monthly."
        >

        I find that the Sprint Backlog is the answer to the above pattern.
        From day 1 you can see your goal, and from day 2 you can see if
        you're aiming for it or goofing off. That is, if your Sprint Backlog
        items are atomic enough to be clearly measurable.

        However, we too struggle with finding a good rhythm... so far I am
        tryng to find it through the reality check of "what worked/what
        didn't/what shall we improve this time?". Right now, I think that
        the "freak out" time is the result of inaccurate Sprint Backlog
        planning... missing or chronically underestimated tasks. And yes,
        that can seem to take "too long". So I will be watching this thread
        to see what others can suggest...

        :-)
        deb
      • Mike Cohn
        Hi Daniel-- ... I don t know that you d be doing something monthly but I do think it s important to plan beyond the current sprint horizon (even if the sprint
        Message 3 of 14 , Nov 26, 2003
        • 0 Attachment
          Hi Daniel--


          > 1. If we do detailed task planning for a week at a time, and continue to
          > do coarse-grained planning in the overall product backlog, would we still
          > be doing any monthly planning, and if so what?
          I don't know that you'd be doing something monthly but I do think it's
          important to plan beyond the current sprint horizon (even if the sprint is a
          month). Without this Scrum can become a bit like a greedy algorithm. Imagine
          you're hiking and want to reach a particular summit. Each morning you start
          a one-day sprint to the highest peak you can see. You'll almost certainly
          end up reaching a few false peaks. If instead you take a bit of a bigger
          view you'll see this and can plan the proper route overall. With month-long
          iterations I encourage teams to start by looking at 4-6 months, just for a
          rough picture of what we want done. After about that amount of time we take
          another look far forward. With week-long sprints you may want to look ahead
          6-8 weeks, effectively doing XP release planning.


          > 2. Given that we're working in weekly increments, can our product owner
          > reprioritize what he wants done on a week-by-week basis, instead of month
          > by month? Keep in mind that in our case, the product owner is "one of us".

          > The external stakeholders would still be steering us on a monthly basis.
          Absolutely. Otherwise I wouldn't really call those one-week sprints. Why
          have the external stakeholders steer you once a month? If you keep it that
          way I'm not sure you get out of the freak out-get intense cycle at the end
          of your months.

          > 3. The sprint review at the end of the month is a big milestone that we
          > take seriously and gives us something to shoot for. What sort of mini-
          > milestone can we put in place to make the end-of-the-week deadline seem
          > real?
          You need a sprint review at the end of the sprint. You still need to stick
          to the discipline of delivering fully functional (tested) code at the end of
          the sprint. If you're thinking that your external stakeholders don't want to
          have a sprint review every week (which is usually the case) then try two
          week sprints, which is probably your best bet right now anyway.

          > 4. We don't want to break Scrum by altering its core practices. Do we risk

          > doing that here, and if so how?
          I've used Scrum with one to four week iterations (not varying much on a
          project, these are different projects). It works either way. A team that
          "gets it" is best off with two week sprints in my mind but I almost always
          start with four week sprints. If you keep all the practices in place--that
          is, do sprint planning and sprint review meetings, production-quality code
          at the end of the sprint, etc--then you don't really break Scrum.

          Good luck and let us know how it goes.

          -Mike


          -----Original Message-----
          From: gackle@... [mailto:gackle@...]
          Sent: Tuesday, November 25, 2003 7:59 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Nesting weekly iterations within monthly sprints

          My team have been using Scrum successfully. We now wish to experiment with
          shorter iterations, and would like some advice.

          A few months ago there was a thread on this topic, "Sprint.length < 30,"
          which I'll summarize here. Some people felt that 30 day iterations are
          optimal for delivering increments of functionality. Others questioned this
          and pointed out that XP teams routinely use weekly iterations. Several posts
          argued that the optimal length depends on the personality of the team.

          I want to ask about this from a different angle: if a Scrum team does want
          to experiment with shorter iterations, how might it best proceed? We want to
          experiment but we don't want to mess with the synergy of the core Scrum
          practices.

          For us, a monthly cycle is natural for interacting with the "external
          world". We're a small team in a large company. Our product owner is very
          much part of the team but our upper managers are not. Meeting with them for
          a review every month, and being shielded from interference in the meantime,
          is just right for both sides.

          Where the monthly cycle is less natural is in our "internal world" of
          planning and completing tasks. Our monthly pattern goes like this: "Meander,
          meander, meander, realize there isn't much time left, freak out, get
          intense, ok we're done. Repeat monthly."

          We seem to be running up against a basic block: psychologically, a month is
          "a long time". We're like the primitive tribe whose counting system goes "1,
          2, 3, many." A month is on the "many" side. The brain doesn't seem to take
          it seriously enough. Only when the deadline (the sprint review) moves within
          the 'serious' range does reality kick in. At that point focus seems to occur
          spontaneously. But we're left regretting our lack of focus earlier in the
          sprint.

          There's another aspect too. The detailed monthly planning feels onerous and
          is taking way too long. We're planning tasks that none of us may touch for
          another 3 weeks. It reminds me of how I used to feel doing up-front design
          for code I wasn't going to be writing any time soon. It feels burdensome.
          Also, for us, it's pseudo-accurate since we're trying to figure out too much
          in advance.

          We want to experiment with nesting shorter cycles within the month. Our hope
          is that since a week is psychologically "not much time", we might spend more
          of each month on focused, productive work.

          Here are the questions we came up with:

          1. If we do detailed task planning for a week at a time, and continue to do
          coarse-grained planning in the overall product backlog, would we still be
          doing any monthly planning, and if so what?

          2. Given that we're working in weekly increments, can our product owner
          reprioritize what he wants done on a week-by-week basis, instead of month by
          month? Keep in mind that in our case, the product owner is "one of us". The
          external stakeholders would still be steering us on a monthly basis.

          3. The sprint review at the end of the month is a big milestone that we take
          seriously and gives us something to shoot for. What sort of mini-milestone
          can we put in place to make the end-of-the-week deadline seem real?

          4. We don't want to break Scrum by altering its core practices. Do we risk
          doing that here, and if so how?

          Please advise!

          - Daniel




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Brad Grant
          ... experiment with shorter iterations, and would like some advice. ... 30, which I ll summarize here. Some people felt that 30 day iterations are optimal for
          Message 4 of 14 , Nov 26, 2003
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, gackle@s... wrote:
            > My team have been using Scrum successfully. We now wish to
            experiment with shorter iterations, and would like some advice.
            >
            > A few months ago there was a thread on this topic, "Sprint.length <
            30," which I'll summarize here. Some people felt that 30 day
            iterations are optimal for delivering increments of functionality.
            Others questioned this and pointed out that XP teams routinely use
            weekly iterations. Several posts argued that the optimal length
            depends on the personality of the team.
            >
            > I want to ask about this from a different angle: if a Scrum team
            does want to experiment with shorter iterations, how might it best
            proceed? We want to experiment but we don't want to mess with the
            synergy of the core Scrum practices.

            Then before you consider it, ensure that all stakeholders and
            development staff is familiar enough with the process as recommended.

            >
            > For us, a monthly cycle is natural for interacting with
            the "external world". We're a small team in a large company. Our
            product owner is very much part of the team but our upper managers
            are not. Meeting with them for a review every month, and being
            shielded from interference in the meantime, is just right for both
            sides.
            >
            > Where the monthly cycle is less natural is in our "internal world"
            of planning and completing tasks. Our monthly pattern goes like
            this: "Meander, meander, meander, realize there isn't much time left,
            freak out, get intense, ok we're done. Repeat monthly."

            What happens at the Daily Scrums that perpetuates the "meander"
            mentality? Is there enough work selected for the Sprint Backlog?
            >
            > We seem to be running up against a basic block: psychologically, a
            month is "a long time". We're like the primitive tribe whose counting
            system goes "1, 2, 3, many." A month is on the "many" side. The brain
            doesn't seem to take it seriously enough. Only when the deadline (the
            sprint review) moves within the 'serious' range does reality kick in.
            At that point focus seems to occur spontaneously. But we're left
            regretting our lack of focus earlier in the sprint.

            If a month is your production target, what about weekly test
            environment targets within?
            >
            > There's another aspect too. The detailed monthly planning feels
            onerous and is taking way too long. We're planning tasks that none of
            us may touch for another 3 weeks. It reminds me of how I used to feel
            doing up-front design for code I wasn't going to be writing any time
            soon. It feels burdensome. Also, for us, it's pseudo-accurate since
            we're trying to figure out too much in advance.
            >
            > We want to experiment with nesting shorter cycles within the month.
            Our hope is that since a week is psychologically "not much time", we
            might spend more of each month on focused, productive work.
            >
            > Here are the questions we came up with:
            >
            > 1. If we do detailed task planning for a week at a time, and
            continue to do coarse-grained planning in the overall product
            backlog, would we still be doing any monthly planning, and if so what?
            >
            > 2. Given that we're working in weekly increments, can our product
            owner reprioritize what he wants done on a week-by-week basis,
            instead of month by month? Keep in mind that in our case, the product
            owner is "one of us". The external stakeholders would still be
            steering us on a monthly basis.
            >
            > 3. The sprint review at the end of the month is a big milestone
            that we take seriously and gives us something to shoot for. What sort
            of mini-milestone can we put in place to make the end-of-the-week
            deadline seem real?
            >
            > 4. We don't want to break Scrum by altering its core practices. Do
            we risk doing that here, and if so how?

            It sounds as if I operate in a very similar environment to yours, and
            tweaking the Scrum process is always tempting.

            Fortunately, our internal deployment cycle coincides somewhat
            naturally with what I believe your trying to achieve.
            We perform daily development environment builds, weekly test builds
            and monthly production releases.

            Given this wrapper, we meet bi-weekly with our product owner to
            ensure Sprint goal interpretation and planning. Since we include
            both new enhancement and defect maintenance in the backlog, we can be
            somewhat flexible if priorities change within the Sprint. When this
            is the case, usually certain targeted "bug fixes" are reprioritized
            back to the product backlog in favor of more critical updates
            required before the production release.

            The key for us is having everyone on board with the process, being
            highly communicative and honest. Daily Scrums within the development
            team dissuade the "meander" issue, and the team focuses on
            productivity, even if it means approaching the product owner for more
            Sprint backlog.

            Respectfully,
            Brad

            >
            > Please advise!
            >
            > - Daniel
          • Ken Schwaber
            Dan, The main issue is the granularity of the product backlog and the content of the demonstration at the sprint review meeting. The shorter the iteration, the
            Message 5 of 14 , Nov 26, 2003
            • 0 Attachment
              Dan,
              The main issue is the granularity of the product backlog and the content of
              the demonstration at the sprint review meeting. The shorter the iteration,
              the finer the granularity; shorter sprints don't provide as much time to
              reduce larger grained requirements into specifications through analysis.
              Unfortunately, fine grained product backlog often is at a specification
              level where it is hard for the product owner to assess business value and
              relative priority. If you do this, let me know how it goes.
              Ken

              -----Original Message-----
              From: gackle@... [mailto:gackle@...]
              Sent: Tuesday, November 25, 2003 9:59 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Nesting weekly iterations within monthly
              sprints


              My team have been using Scrum successfully. We now wish to experiment with
              shorter iterations, and would like some advice.

              A few months ago there was a thread on this topic, "Sprint.length < 30,"
              which I'll summarize here. Some people felt that 30 day iterations are
              optimal for delivering increments of functionality. Others questioned this
              and pointed out that XP teams routinely use weekly iterations. Several posts
              argued that the optimal length depends on the personality of the team.

              I want to ask about this from a different angle: if a Scrum team does want
              to experiment with shorter iterations, how might it best proceed? We want to
              experiment but we don't want to mess with the synergy of the core Scrum
              practices.

              For us, a monthly cycle is natural for interacting with the "external
              world". We're a small team in a large company. Our product owner is very
              much part of the team but our upper managers are not. Meeting with them for
              a review every month, and being shielded from interference in the meantime,
              is just right for both sides.

              Where the monthly cycle is less natural is in our "internal world" of
              planning and completing tasks. Our monthly pattern goes like this: "Meander,
              meander, meander, realize there isn't much time left, freak out, get
              intense, ok we're done. Repeat monthly."

              We seem to be running up against a basic block: psychologically, a month is
              "a long time". We're like the primitive tribe whose counting system goes "1,
              2, 3, many." A month is on the "many" side. The brain doesn't seem to take
              it seriously enough. Only when the deadline (the sprint review) moves within
              the 'serious' range does reality kick in. At that point focus seems to occur
              spontaneously. But we're left regretting our lack of focus earlier in the
              sprint.

              There's another aspect too. The detailed monthly planning feels onerous and
              is taking way too long. We're planning tasks that none of us may touch for
              another 3 weeks. It reminds me of how I used to feel doing up-front design
              for code I wasn't going to be writing any time soon. It feels burdensome.
              Also, for us, it's pseudo-accurate since we're trying to figure out too much
              in advance.

              We want to experiment with nesting shorter cycles within the month. Our hope
              is that since a week is psychologically "not much time", we might spend more
              of each month on focused, productive work.

              Here are the questions we came up with:

              1. If we do detailed task planning for a week at a time, and continue to do
              coarse-grained planning in the overall product backlog, would we still be
              doing any monthly planning, and if so what?

              2. Given that we're working in weekly increments, can our product owner
              reprioritize what he wants done on a week-by-week basis, instead of month by
              month? Keep in mind that in our case, the product owner is "one of us". The
              external stakeholders would still be steering us on a monthly basis.

              3. The sprint review at the end of the month is a big milestone that we take
              seriously and gives us something to shoot for. What sort of mini-milestone
              can we put in place to make the end-of-the-week deadline seem real?

              4. We don't want to break Scrum by altering its core practices. Do we risk
              doing that here, and if so how?

              Please advise!

              - Daniel




              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...

              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Boris Gloger
              Hi Daniel, I think the interesting point is the emphasis of personality of our team - and by the way, I think your problem is not the iteration time, but the
              Message 6 of 14 , Nov 27, 2003
              • 0 Attachment
                Hi Daniel,

                I think the interesting point is the emphasis of personality of our
                team - and by the way, I think your problem is not the iteration time,
                but the "personality" of our team.

                1) So is mine, or was mine. You described in one of your paragraphs the
                so called students syndrom: I wait as long as possible with starting a
                task, and therefore I eat up my buffer, that I instinctally estimated,
                and then I get into trouble if something went wrong.

                2) On the other side I have the feeling (based on what I read) that you
                have the problem of planning. ("detailed monthly planning").

                Both effects are part of your team personality.

                a) What do you want to achive by shortening the iteration time? - Do
                you want to increase the time pressure to overcome the students
                syndrom? If yes, you imedially get in trouble with point 2) what is
                detailed planning. So I would say your team does have a the problem of
                not being disciplined enough to work hard from the beginning on. Ken
                mentioned in Edinburgh, that he is able to see based on the Burn Down
                Chart, what kind of team personality he is confronted with. Maybe your
                team is one that has this specific behavior. But as long as you meet
                always the target of your Sprint? So what? Why shortening the iteration
                time. Do you want to get more out of the iterations? If yes - I think
                that shortening the iterations is not the right thing.

                > 1. If we do detailed task planning for a week at a time, and continue
                > to do coarse-grained planning in the overall product backlog, would we
                > still be doing any monthly planning, and if so what?
                >

                Why do you want to do detailed task planing? We do only the Sprint
                Backlog, Sometimes it is only a copy of the Product Backlog, because
                the feature itself is small enough for being a task. (Our Product
                Backlog consist not only on business features, but on the things we
                need to do, handovers, writing articles, prepare for christmas, ) And
                from this moment on it is the problem of the team to co-ordinate their
                activities. Everybody is assigned to a task and did a commitment to
                deliver.

                So - do you do more? I would not think about a design issue three weeks
                in advance. Why?


                > 2. Given that we're working in weekly increments, can our product
                > owner reprioritize what he wants done on a week-by-week basis, instead
                > of month by month? Keep in mind that in our case, the product owner is
                > "one of us". The external stakeholders would still be steering us on a
                > monthly basis.
                >

                I would say for the product owner in my own team, of course. We do a
                daily internal reprio. Whenever someone is ill, or we figure out that
                we need to do something first before we can do the next step. But this
                does not tackle our delivery.

                > 3. The sprint review at the end of the month is a big milestone that
                > we take seriously and gives us something to shoot for. What sort of
                > mini-milestone can we put in place to make the end-of-the-week
                > deadline seem real?
                >

                We do 2 week sprints, and we do after every two weeks, after the launch
                / release our 2 hour retrospective. And we have a lot of fun, when we
                do it.

                > 4. We don't want to break Scrum by altering its core practices. Do we
                > risk doing that here, and if so how?
                >

                I would say: No - because Scrum is more than the skeleton. It is more a
                question of the way you want to work.

                We do change and adapt our process after each retrospective. Whenever
                we figured out something could be improved we try it.

                Daniel - I hope this sounds not to smart (hope this is the right word -
                I do not want to come over with the feeling, I do know everything. I
                only want to say, that I have the feeling, that you currently struggle
                with the how of implementation of Scrum - and this is normal.

                We - no I, needed 8 month from the first idea - to get the daily scrums
                working in a way I wanted. After this I needed 3 iterations to find a
                way to organize the planing session in a way it was not boring and done
                in a way that everybody get a feeling what we need to do next time.

                And I still change this when I feel I can do it better.

                I needed 3 retrospectives in the last month to get my team into the
                habit of using the feedback meetinig as a plattform for laugh, sharing
                ideas and being open. Any new contracter that is involved in our
                feedback sessions has problems in the beginning to use this forum as a
                platform.

                We still struggeling with our process. We do not have test driven
                development. That is something I want to implement. But it was very
                hard to convince my developers to have a look at it, and to play them
                free. Now we started to have a look after stabelizing our release
                process. So from this point in view, we are at the beginning.

                And we improve or risk our communication with our client every
                iteration. This is not very simple because they do not see, that they
                have to wait for two weeks, when the have now an idea. Or they start
                with questioning why I do not put more resources on X, or why I did not
                change the way we work, or...

                You see - we are not perfect - but what I strongly believe, we will
                develop a process that is working for us, SCRUM and its rules are only
                the start, not the end. Although I really love SCRUM.

                Hope this was helpful

                Boris




                On Mittwoch, Nov 26, 2003, at 03:58 Europe/Vienna, gackle@... wrote:

                > My team have been using Scrum successfully. We now wish to experiment
                > with shorter iterations, and would like some advice.
                >
                > A few months ago there was a thread on this topic, "Sprint.length <
                > 30," which I'll summarize here. Some people felt that 30 day
                > iterations are optimal for delivering increments of functionality.
                > Others questioned this and pointed out that XP teams routinely use
                > weekly iterations. Several posts argued that the optimal length
                > depends on the personality of the team.
                >
                > I want to ask about this from a different angle: if a Scrum team does
                > want to experiment with shorter iterations, how might it best proceed?
                > We want to experiment but we don't want to mess with the synergy of
                > the core Scrum practices.
                >
                > For us, a monthly cycle is natural for interacting with the "external
                > world". We're a small team in a large company. Our product owner is
                > very much part of the team but our upper managers are not. Meeting
                > with them for a review every month, and being shielded from
                > interference in the meantime, is just right for both sides.
                >
                > Where the monthly cycle is less natural is in our "internal world" of
                > planning and completing tasks. Our monthly pattern goes like this:
                > "Meander, meander, meander, realize there isn't much time left, freak
                > out, get intense, ok we're done. Repeat monthly."
                >
                > We seem to be running up against a basic block: psychologically, a
                > month is "a long time". We're like the primitive tribe whose counting
                > system goes "1, 2, 3, many." A month is on the "many" side. The brain
                > doesn't seem to take it seriously enough. Only when the deadline (the
                > sprint review) moves within the 'serious' range does reality kick in.
                > At that point focus seems to occur spontaneously. But we're left
                > regretting our lack of focus earlier in the sprint.
                >
                > There's another aspect too. The detailed monthly planning feels
                > onerous and is taking way too long. We're planning tasks that none of
                > us may touch for another 3 weeks. It reminds me of how I used to feel
                > doing up-front design for code I wasn't going to be writing any time
                > soon. It feels burdensome. Also, for us, it's pseudo-accurate since
                > we're trying to figure out too much in advance.
                >
                > We want to experiment with nesting shorter cycles within the month.
                > Our hope is that since a week is psychologically "not much time", we
                > might spend more of each month on focused, productive work.
                >
                > Here are the questions we came up with:
                >
                > 1. If we do detailed task planning for a week at a time, and continue
                > to do coarse-grained planning in the overall product backlog, would we
                > still be doing any monthly planning, and if so what?
                >
                > 2. Given that we're working in weekly increments, can our product
                > owner reprioritize what he wants done on a week-by-week basis, instead
                > of month by month? Keep in mind that in our case, the product owner is
                > "one of us". The external stakeholders would still be steering us on a
                > monthly basis.
                >
                > 3. The sprint review at the end of the month is a big milestone that
                > we take seriously and gives us something to shoot for. What sort of
                > mini-milestone can we put in place to make the end-of-the-week
                > deadline seem real?
                >
                > 4. We don't want to break Scrum by altering its core practices. Do we
                > risk doing that here, and if so how?
                >
                > Please advise!
                >
                > - Daniel
                >
                >
                >
                > ------------------------ Yahoo! Groups Sponsor
                > ---------------------~-->
                > KnowledgeStorm has over 22,000 B2B technology solutions. The most
                > comprehensive IT buyers' information available. Research, compare,
                > decide. E-Commerce | Application Dev | Accounting-Finance | Healthcare
                > | Project Mgt | Sales-Marketing | More
                > http://us.click.yahoo.com/IMai8D/UYQGAA/cIoLAA/9EfwlB/TM
                > ---------------------------------------------------------------------
                > ~->
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >
                >
                >
                >
                Boris Gloger

                Vienna, Austria
                +43 699 1699 4977
              • Daniel Gackle
                Thanks to everyone who replied about shorter iterations. If anything interesting comes of our experiment I ll report back. I m still intrigued by the thought
                Message 7 of 14 , Dec 1, 2003
                • 0 Attachment
                  Thanks to everyone who replied about shorter iterations. If anything
                  interesting comes of our experiment I'll report back.

                  I'm still intrigued by the thought that perhaps the monthly and weekly
                  cycles don't contradict each other, but address two different concerns. For
                  example, when Ken said...

                  > The shorter the iteration, the finer the granularity;
                  > shorter sprints don't provide as much time to reduce larger
                  > grained requirements into specifications through analysis.
                  > Unfortunately, fine grained product backlog often is at a
                  > specification level where it is hard for the product owner
                  > to assess business value and relative priority.

                  ... he was talking about external stakeholders steering the development team
                  according to business value. By contrast, when Ron said...

                  > I believe that for many of us, a month seems like forever. There's little
                  > sense of urgency for a deadline that's a whole month away. I suspect
                  that's
                  > why many teams like the shorter iteration sizes.

                  ... he was talking about the psychology of day-to-day development. Two
                  different perspectives, extra- and intra-team. (Unless, of course, I'm
                  misinterpreting.)

                  This matches our experience, which is that monthly interaction with the
                  larger world "out there" works very well, while attempting to organize the
                  development tasks on a monthly basis does not. Please note, I'm not talking
                  about going for a month without any guidance from business people. We have a
                  domain expert who functions much like our XP customer, and I wouldn't want
                  to go even a day or two without his feedback.

                  It's not that we're not succeeding with monthly iterations; we are. It's
                  just that we've hit a ceiling. Gut feeling tells me that ceiling is the same
                  thing that Ron's talking about. But it's too early to tell.

                  - Daniel
                • Ron Jeffries
                  ... Yes, please do! If we can help, let us know! Ron Jeffries www.XProgramming.com I could be wrong, of course. It s just not the way to bet.
                  Message 8 of 14 , Dec 2, 2003
                  • 0 Attachment
                    On Tuesday, December 2, 2003, at 1:48:14 AM, Daniel Gackle wrote:

                    > Thanks to everyone who replied about shorter iterations. If anything
                    > interesting comes of our experiment I'll report back.

                    Yes, please do! If we can help, let us know!

                    Ron Jeffries
                    www.XProgramming.com
                    I could be wrong, of course. It's just not the way to bet.
                  • Brad Appleton
                    ... I remember a short article written by Jim Highsmith entitled Release, Milestone and Iteration Planning which described the need for all three of those
                    Message 9 of 14 , Dec 2, 2003
                    • 0 Attachment
                      On Mon, Dec 01, 2003 at 11:48:14PM -0700, Daniel Gackle wrote:
                      > I'm still intrigued by the thought that perhaps the monthly and weekly
                      > cycles don't contradict each other, but address two different concerns.

                      I remember a short article written by Jim Highsmith entitled
                      "Release, Milestone and Iteration Planning" which described
                      the need for all three of those things in an agile project
                      (i.e. a Release plan that has both milestones and iterations
                      planned within it) where the iterations are smaller-grained
                      than the milestones:

                      Many project managers can't fathom a 12-month project broken
                      down into two-week iterations -- and in some ways this is
                      understandable. Once projects go beyond four to five months,
                      they usually need interim checkpoints at two-week intervals
                      and at the project's end. Larger projects that employ
                      distributed teams or vendor-supplied components will have
                      problems synchronizing every two weeks. So, many projects
                      will require three (or even more) levels of iteration.

                      The longest period is the release cycle. Products are
                      generally released to customers periodically -- once every
                      year or 18 months, for example. As such, "release" implies
                      a release for customer use.

                      On the other end of the spectrum, an iteration is used by a
                      development team to focus on small increments of work. In
                      agile software development, an iteration might be two
                      weeks (XP), 30 days (Scrum), or slightly longer for some
                      projects. If you're building an airplane, the iterations
                      will surely be longer.

                      Milestones are intermediate points -- usually from one to
                      three months. Milestones can have both a project management
                      function and a technical function. From a project management
                      perspective, milestones provide a chance to review progress
                      and make more significant project adjustments. For example,
                      while most agilests recommend project mini-retrospectives
                      at the end of each iteration, most would actually employ
                      them every two to three iterations if the iterations were
                      short (two weeks). Milestones can also be used as major
                      synchronization and integration points. For a product that
                      has both hardware and software components, monthly (or even
                      longer) synchronizations may be entirely adequate. On the
                      other hand, if less-frequent synchronizations are going
                      poorly, it might indicate that the synchronization should
                      occur more frequently.

                      He then goes on to talk about the lengths/durations of each
                      above as being relative, and can certainly be longer or shorter,
                      but the relative "scale" of each as compared to the other
                      seems to stay consistent.
                      --
                      Brad Appleton <brad@...> www.bradapp.net
                      Software CM Patterns (www.scmpatterns.com)
                      Effective Teamwork, Practical Integration
                      "And miles to go before I sleep." -- Robert Frost
                    • David Vydra
                      Daniel, ... is a long time . We re like the primitive tribe whose counting system goes 1, 2, 3, many. A month is on the many side. The brain doesn t seem
                      Message 10 of 14 , Dec 2, 2003
                      • 0 Attachment
                        Daniel,
                        >
                        > We seem to be running up against a basic block: psychologically, a month
                        is "a long time". We're like the primitive tribe whose counting system goes
                        "1, 2, 3, many." A month is on the "many" side. The brain doesn't seem to
                        take it seriously enough. Only when the deadline (the sprint review) moves
                        within the 'serious' range does reality kick in. At that point focus seems
                        to occur spontaneously. But we're left regretting our lack of focus earlier
                        in the sprint.
                        >

                        This is a very interesting observation. I wonder if the 'slack' that you
                        feel in week one is actually good for the process. Often you need to be
                        'relaxed' when experimenting or learning.

                        This question has come up many times before. I will make a prediction that
                        many mature Agile teams will move to a variable length iteration, perhaps on
                        a bell curve, because at the beginning and tail end of a project shorter
                        iterations seem more appropriate. (hmm, this idea may earn me some serious
                        flame)

                        Regards,
                        David
                      • Ron Jeffries
                        ... Yes ... C3 ran one-week iterations for quite a while prior to one release. That s the longest time I ve ever spent in that mode. I found it tiring and
                        Message 11 of 14 , Dec 3, 2003
                        • 0 Attachment
                          On Wednesday, December 3, 2003, at 2:27:36 AM, David Vydra wrote:

                          > This is a very interesting observation. I wonder if the 'slack' that you
                          > feel in week one is actually good for the process. Often you need to be
                          > 'relaxed' when experimenting or learning.

                          Yes ...

                          C3 ran one-week iterations for quite a while prior to one release. That's
                          the longest time I've ever spent in that mode. I found it tiring and
                          maddening after a while, like pounding away at a dead run forever. I
                          believe that most of the team found it so.

                          An interation seems to want to have a kind of relaxed opening. Warming up,
                          stretching the muscles, finding where we are tight or a little bit achy.
                          Then we reach our stride, moving along at our best pace, running almost
                          effortlessly, as if we could do it forever. Then the finish line looms. We
                          gather it all up and push hard, down to the end.

                          In XP, it's probably not good to collapse at the finish line like a runner
                          who has given it all. But there is a sense of a gathering final sprint
                          nonetheless.

                          > This question has come up many times before. I will make a prediction that
                          > many mature Agile teams will move to a variable length iteration, perhaps on
                          > a bell curve, because at the beginning and tail end of a project shorter
                          > iterations seem more appropriate.

                          I'm inclined, almost, to agree. A sharp team can start at one week -- I'm
                          working with one now who, despite just beginning with XP, are doing fine.
                          On the other hand, the first few iterations were pretty shaky.

                          I do believe that the one-week cycle enables -- requires -- the team to
                          learn how to break big things down into fine bites, and that has immense
                          value. Most teams feel that they can do almost anything in a month, and
                          they're right. What they don't know is that almost anything can be broken
                          down into steps that take a day -- even a couple of hours. That's well
                          worth learning.

                          I still fear one-month iterations. But Scrum does them successfully, and
                          Alistair has seen them work successfully, so I don't doubt that they can be
                          good. I do think that two weeks, or even one, will shake out a higher level
                          of performance and learning of a certain kind. But one-weekers for a year?
                          I don't think I'd like that either.


                          Something to think about: If an iteration works well when it can have a
                          sense of loosening up, hitting stride, sprinting to the finish, perhaps a
                          project should have that same feeling. Perhaps variable-length iterations
                          could give it that.

                          Ron Jeffries
                          www.XProgramming.com
                          FEAR = Fantasy Experienced As Reality
                        • slightlynew
                          Brad, ... I was in a discussion of this topic only yesterday. Can you provide a link to this article? Daniel
                          Message 12 of 14 , Dec 3, 2003
                          • 0 Attachment
                            Brad,

                            > I remember a short article written by Jim Highsmith entitled
                            > "Release, Milestone and Iteration Planning" which described
                            > the need for all three of those things in an agile project
                            > (i.e. a Release plan that has both milestones and iterations
                            > planned within it) where the iterations are smaller-grained
                            > than the milestones

                            I was in a discussion of this topic only yesterday. Can you provide a
                            link to this article?

                            Daniel
                          • Brad Appleton
                            ... I looked for it on Google and at the cutter sight as well as Highsmith s site. Alas I could not find it. I can send you a copy of the email I received - I
                            Message 13 of 14 , Dec 3, 2003
                            • 0 Attachment
                              On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
                              > Brad,
                              >
                              > > I remember a short article written by Jim Highsmith entitled
                              > > "Release, Milestone and Iteration Planning" which described
                              > > the need for all three of those things in an agile project
                              > > (i.e. a Release plan that has both milestones and iterations
                              > > planned within it) where the iterations are smaller-grained
                              > > than the milestones
                              >
                              > I was in a discussion of this topic only yesterday. Can you provide a
                              > link to this article?

                              I looked for it on Google and at the cutter sight as well as Highsmith's site.
                              Alas I could not find it. I can send you a copy of the email I received - I worry about posting it to the list in its entirety without permission. Maybe Highsmith himself can advise (or make it available on the web) as I've Cc:ed him on this message.

                              --
                              Brad Appleton <brad@...> www.bradapp.net
                              Software CM Patterns (www.scmpatterns.com)
                              Effective Teamwork, Practical Integration
                              "And miles to go before I sleep." -- Robert Frost
                            • Brad Appleton
                              ... Jim Highsmith said it was in an e-advisory newsletter from the cutter consortium. He gave me permission (via personal email) to post the newsletter to
                              Message 14 of 14 , Dec 3, 2003
                              • 0 Attachment
                                On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
                                > Brad,
                                >
                                > > I remember a short article written by Jim Highsmith entitled
                                > > "Release, Milestone and Iteration Planning" which described
                                > > the need for all three of those things in an agile project
                                > > (i.e. a Release plan that has both milestones and iterations
                                > > planned within it) where the iterations are smaller-grained
                                > > than the milestones
                                >
                                > I was in a discussion of this topic only yesterday. Can you
                                > provide a link to this article?

                                Jim Highsmith said it was in an "e-advisory" newsletter from
                                the cutter consortium. He gave me permission (via personal
                                email) to post the newsletter to the list provided I did so
                                in its entirety (including the ads). Here it is after my
                                email signature below.

                                Cheers!
                                --
                                Brad Appleton <brad@...> www.bradapp.net
                                Software CM Patterns (www.scmpatterns.com)
                                Effective Teamwork, Practical Integration
                                "And miles to go before I sleep." -- Robert Frost

                                ************************************************************


                                Welcome to the Agile Project Management E-Mail Advisor, a
                                weekly electronic briefing from Cutter Consortium's Agile Project
                                Management Advisory Service.

                                RELEASE, MILESTONE,
                                AND ITERATION PLANNING

                                by Jim Highsmith, Director, Agile Project Management Practice
                                http://www.cutter.com/consultants/jhbio.html

                                When people first learn about agile or iterative development, they
                                often think just in terms of short timeboxed iterations. However,
                                there are two components to iterative planning -- the short iterations
                                and the use of features rather than tasks. Basing plans on the
                                product's features (and its architecture, which is instantiated by
                                features) keeps the project team and the product's customers
                                synchronized (because the customers understand the product
                                even though they may not understand the technical activities). It also
                                focuses the team on delivering the product rather than focusing on
                                intermediate documentation artifacts.

                                It's not that documentation artifacts are not useful; no one would
                                consider building, say, an airplane or an automobile without extensive
                                documentation. The problem is not documentation per se but that
                                project teams often get lost producing intermediate artifacts that
                                have little bearing on the final product. Feature-based planning
                                attempts to overcome this problem.

                                Many project managers can't fathom a 12-month project broken
                                down into two-week iterations -- and in some ways this is
                                understandable. Once projects go beyond four to five months, they
                                usually need interim checkpoints at two-week intervals and at the
                                project's end. Larger projects that employ distributed teams or
                                vendor-supplied components will have problems synchronizing
                                every two weeks. So, many projects will require three (or even
                                more) levels of iteration.

                                The longest period is the release cycle. Products are generally
                                released to customers periodically -- once every year or 18
                                months, for example. As such, "release" implies a release for
                                customer use.

                                On the other end of the spectrum, an iteration is used by a
                                development team to focus on small increments of work. In agile
                                software development, an iteration might be two weeks (XP), 30
                                days (Scrum), or slightly longer for some projects. If you're building
                                an airplane, the iterations will surely be longer.

                                Milestones are intermediate points -- usually from one to three
                                months. Milestones can have both a project management function
                                and a technical function. From a project management perspective,
                                milestones provide a chance to review progress and make more
                                significant project adjustments. For example, while most agilests
                                recommend project mini-retrospectives at the end of each iteration,
                                most would actually employ them every two to three iterations if
                                the iterations were short (two weeks). Milestones can also be used
                                as major synchronization and integration points. For a product that
                                has both hardware and software components, monthly (or even
                                longer) synchronizations may be entirely adequate. On the other
                                hand, if less-frequent synchronizations are going poorly, it might
                                indicate that the synchronization should occur more frequently.

                                Iterations produce acceptance-tested features. The goal is to have
                                a partial-feature product that could be deployed at the end of any
                                iteration -- that is, the features, testing, documentation, and other
                                product deliverables could be packaged up and deployed. Iterative
                                and incremental development are differentiated by this actual
                                deployment. In some types of software development -- many Web-
                                based systems, for example -- this goal can be achieved. By early
                                deployment of partially completed products, early returns can
                                boost ROI, and early feedback from customers can enhance the
                                development during subsequent iterations. For other products
                                (including a number of software products), this goal of being able
                                to deploy at any iteration keeps the team on its toes but won't
                                always be achievable. If a competitor has a product on the market
                                with a certain capability, it won't be feasible to deploy your product
                                until it has comparable capability.

                                Some people think agile development gives them an opportunity to
                                dive in and build (or code, in the software arena). They condemn
                                agile methods, saying they spend little or no time on early
                                requirements gathering or architectural issues. On the other hand,
                                there has been an equally negative reaction to months and months
                                of planning, requirements specification, and architectural
                                philosophizing. There is obviously a balance point, but many
                                arguments imply there is no middle ground. Iteration 0 is a practice
                                to help teams find that middle ground. The "zero" implies that nothing
                                useful to the customer -- features, in other words -- gets delivered
                                in this time period. However, the fact that we have designated an
                                iteration implies that the work is useful to some other stakeholder.

                                Though the range of issues can be broad, the outcome is the same --
                                some projects require more extensive initialization work than others.
                                The key to effectively utilizing Iteration 0 is to balance the possible
                                advantages of further planning with the growing disadvantage of
                                lack of customer-deliverable features. There are always tradeoffs.
                                If the cost of a technical platform change is very high, then additional
                                work to improve the odds of an initial correct decision may be
                                justified. Iteration 0 for a next-generation jumbo jetliner will be
                                much different than that for a standalone software product.

                                Iterative planning is an integral part of agile project management;
                                however, there are many variations on the theme that are determined
                                by the specifics of a particular product or project. There isn't a
                                single right way or a single iteration length that works for every
                                project.

                                -- Jim Highsmith, Director, Agile Project Management Practice
                                http://www.cutter.com/consultants/jhbio.html
                                +++++++++++++++++++++++++++++++++++

                                Learn more about iterative planning and agile project management
                                when you bring Jim Highsmith and his highly popular *Agile Project
                                Management: Innovation in Action* workshop into your training
                                room! For more information, visit
                                http://www.cutter.com/workshops/22.html , call David Gijsbers
                                at +1 781 641 5104 or send e-mail to david@....
                                +++++++++++++++++++++++++++++++++++

                                The Cutter Consortium report *The Politics of Software Testing*
                                explores approaches for performing just enough testing to create
                                quality software without compromising your IT budget. It reveals how
                                agile and risk-based testing approaches can provide a practical and
                                cost-effective solution to your software testing challenges.

                                This report also explains how to develop an enterprise-wide,
                                structured approach to testing that incorporates business risk
                                management. With this approach, you'll conduct more consistent and
                                rigorous testing, realize quicker returns on your investment and
                                continually reduce testing costs.

                                Order your copy of *The Politics of Software Testing* today for just
                                US $249 (US $264 outside North America). Order online at
                                http://www.cutter.com/bookstore/testing.html , or call
                                +1 781 648 8700, send a fax to +1 781 648 1950 or send e-mail
                                to service@....
                                +++++++++++++++++++++++++++++++++++

                                If you'd like to comment on today's Agile Project Management
                                E-Mail Advisor, send e-mail to apm@..., or send a letter
                                by fax to +1 781 648 8707 or by mail to The Agile Project
                                Management E-Mail Advisor, Cutter Consortium, 37 Broadway,
                                Suite 1, Arlington, MA 02474-5552, USA.
                                +++++++++++++++++++++++++++++++++++

                                To unsubscribe to the Agile Project Management E-Mail Advisor,
                                send e-mail to majordomo@... and include the message
                                "unsubscribe agile_list your-e-mail@..." in the body of
                                the message. Please use all lowercase letters and verify that your
                                e-mail address is correct. Do not include anything but the message
                                "unsubscribe agile_list" and your e-mail address in the body of the
                                message. If you have any problems, please contact Ron Pulicari
                                at rpulicari@....

                                (c) 2003 Cutter Consortium. All rights reserved. Unauthorized
                                reproduction in any form, including forwarding, photocopying,
                                faxing and image scanning, is against the law.

                                To sample our other weekly E-Mail Advisors, you can register at
                                http://www.cutter.com/advisors .
                              Your message has been successfully submitted and would be delivered to recipients shortly.