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

Length of Iteration

Expand Messages
  • Ken Schwaber
    Several weeks ago, I asked what we as a group thought the length of an iteration should be. A surprisingly large number of people preferred one-to-two week
    Message 1 of 19 , Feb 26, 2004
    • 0 Attachment
      Several weeks ago, I asked what we as a group thought the length of
      an iteration should be. A surprisingly large number of people
      preferred one-to-two week iterations. The reasons given mostly had
      to do with team output. A hard thing about Scrum is that many of the
      rules in it have been derived empirically. Yes, Scrum is based in
      empirical process control and relies on frequent inspection and
      adaptation, but the way it is constructed to do so to optimally
      build software that is pleasurable to our customers has been derived
      by trial and error over fourteen years or so. Mary Poppendieck
      refers to these rules as the "swarm behavior" rules; they are simple
      rules that create complex, focused behavior similar to that of ants
      or bees. The problem with this, of course, is that all of this is
      experiential and empirical rather than mathematically provable or
      testable. That is our good and bad news.
      I've noticed over the years that I've been using Scrum that the best
      software has been built when the Sprints are long enough for the
      best creativity to come out of the team, regardless of its
      composition. By best software, I mean great software, not just
      software that was built with optimized productivity. Examples that
      pop to mind are the personalization capabilities of Individual's
      Newspage internet newspaper; as early as 1996 you could customize
      the news you wanted to be served. Or, IDX's teleradiology product,
      which allowed the best radiological minds in the world to
      collaborate real time to produce the best diagnosis. Or, just
      recently, Primavera's release 4.0, which raises the bar in the whole
      project management software marketplace. The teams building each of
      these products had time to let great ideas gestate; they had "slack"
      to be great. Maybe we should change the name from Sprint, which is
      more in line with one and two week iterations, to Create.
      Ken
    • Mike Cohn
      Ken-- I would not recommend changing the name from Sprint (noun and verb) to Create (verb only). The discussions would be too hard and there are many people
      Message 2 of 19 , Feb 26, 2004
      • 0 Attachment
        Ken--

        I would not recommend changing the name from Sprint (noun and verb) to
        Create (verb only). The discussions would be too hard and there are many
        people I've talked to that like the connotations of sprint.

        Great observation about the best software coming from teams doing 30-day
        iterations. I'm one who has spoken out in favor of two-week sprints.
        However, I have to concur with you that the best software I've seen has come
        out of teams doing four-week sprints. However, I find that I have a harder
        time getting a new team to handle four-week sprints. The more rapid learning
        cycle of 2 week sprints serves me much better when introducing Scrum to a
        team. It also facilitates getting Product Owners to buy into the idea that
        they can't change their minds during the sprint. If they get used to that
        with 2 weeks they can later handle it with 4 weeks.

        So--I'll stick with my approach of starting with 2 week sprints then moving
        to four when the team (and organization) can handle it. (This typically
        takes many months.) But--as you often do, you've now explained to me why
        something works that I've observed but didn't understand. Thanks!

        --Mike

        -----Original Message-----
        From: Ken Schwaber [mailto:ken.schwaber@...]
        Sent: Thursday, February 26, 2004 5:21 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Length of Iteration

        Several weeks ago, I asked what we as a group thought the length of
        an iteration should be. A surprisingly large number of people
        preferred one-to-two week iterations. The reasons given mostly had
        to do with team output. A hard thing about Scrum is that many of the
        rules in it have been derived empirically. Yes, Scrum is based in
        empirical process control and relies on frequent inspection and
        adaptation, but the way it is constructed to do so to optimally
        build software that is pleasurable to our customers has been derived
        by trial and error over fourteen years or so. Mary Poppendieck
        refers to these rules as the "swarm behavior" rules; they are simple
        rules that create complex, focused behavior similar to that of ants
        or bees. The problem with this, of course, is that all of this is
        experiential and empirical rather than mathematically provable or
        testable. That is our good and bad news.
        I've noticed over the years that I've been using Scrum that the best
        software has been built when the Sprints are long enough for the
        best creativity to come out of the team, regardless of its
        composition. By best software, I mean great software, not just
        software that was built with optimized productivity. Examples that
        pop to mind are the personalization capabilities of Individual's
        Newspage internet newspaper; as early as 1996 you could customize
        the news you wanted to be served. Or, IDX's teleradiology product,
        which allowed the best radiological minds in the world to
        collaborate real time to produce the best diagnosis. Or, just
        recently, Primavera's release 4.0, which raises the bar in the whole
        project management software marketplace. The teams building each of
        these products had time to let great ideas gestate; they had "slack"
        to be great. Maybe we should change the name from Sprint, which is
        more in line with one and two week iterations, to Create.
        Ken




        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Ken Schwaber
        Two wseek Sprints are training wheels. Who would have thought it. Ken
        Message 3 of 19 , Feb 26, 2004
        • 0 Attachment
          Two wseek Sprints are training wheels. Who would have thought it.
          Ken
          >
          > From: "Mike Cohn" <mike@...>
          > Date: 2004/02/26 Thu PM 06:39:22 CST
          > To: <scrumdevelopment@yahoogroups.com>
          > Subject: RE: [scrumdevelopment] Length of Iteration
          >
          > Ken--
          >
          > I would not recommend changing the name from Sprint (noun and verb) to
          > Create (verb only). The discussions would be too hard and there are many
          > people I've talked to that like the connotations of sprint.
          >
          > Great observation about the best software coming from teams doing 30-day
          > iterations. I'm one who has spoken out in favor of two-week sprints.
          > However, I have to concur with you that the best software I've seen has come
          > out of teams doing four-week sprints. However, I find that I have a harder
          > time getting a new team to handle four-week sprints. The more rapid learning
          > cycle of 2 week sprints serves me much better when introducing Scrum to a
          > team. It also facilitates getting Product Owners to buy into the idea that
          > they can't change their minds during the sprint. If they get used to that
          > with 2 weeks they can later handle it with 4 weeks.
          >
          > So--I'll stick with my approach of starting with 2 week sprints then moving
          > to four when the team (and organization) can handle it. (This typically
          > takes many months.) But--as you often do, you've now explained to me why
          > something works that I've observed but didn't understand. Thanks!
          >
          > --Mike
          >
          > -----Original Message-----
          > From: Ken Schwaber [mailto:ken.schwaber@...]
          > Sent: Thursday, February 26, 2004 5:21 PM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: [scrumdevelopment] Length of Iteration
          >
          > Several weeks ago, I asked what we as a group thought the length of
          > an iteration should be. A surprisingly large number of people
          > preferred one-to-two week iterations. The reasons given mostly had
          > to do with team output. A hard thing about Scrum is that many of the
          > rules in it have been derived empirically. Yes, Scrum is based in
          > empirical process control and relies on frequent inspection and
          > adaptation, but the way it is constructed to do so to optimally
          > build software that is pleasurable to our customers has been derived
          > by trial and error over fourteen years or so. Mary Poppendieck
          > refers to these rules as the "swarm behavior" rules; they are simple
          > rules that create complex, focused behavior similar to that of ants
          > or bees. The problem with this, of course, is that all of this is
          > experiential and empirical rather than mathematically provable or
          > testable. That is our good and bad news.
          > I've noticed over the years that I've been using Scrum that the best
          > software has been built when the Sprints are long enough for the
          > best creativity to come out of the team, regardless of its
          > composition. By best software, I mean great software, not just
          > software that was built with optimized productivity. Examples that
          > pop to mind are the personalization capabilities of Individual's
          > Newspage internet newspaper; as early as 1996 you could customize
          > the news you wanted to be served. Or, IDX's teleradiology product,
          > which allowed the best radiological minds in the world to
          > collaborate real time to produce the best diagnosis. Or, just
          > recently, Primavera's release 4.0, which raises the bar in the whole
          > project management software marketplace. The teams building each of
          > these products had time to let great ideas gestate; they had "slack"
          > to be great. Maybe we should change the name from Sprint, which is
          > more in line with one and two week iterations, to Create.
          > Ken
          >
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        • dennis
          Hi, I m relatively new to the group, but have been following the discussions for about 3 months now. We started back last November using SCRUM and we in fact
          Message 4 of 19 , Feb 26, 2004
          • 0 Attachment

            Hi,

             

            I’m relatively new to the group, but have been following the discussions for about 3 months now. We started back last November using SCRUM and we in fact did exactly as both Ken and Mike stated. We started the first Sprint as 2 weeks. We didn’t put much in it from a goals stand point, but it got everyone on the team into the process. We moved to four week sprints after that and have been using them since.

             

            I would highly recommend anyone just starting out use the 2 week time frame to get your feet wet and don’t commit to much. You need that time for everyone to get into the flow of things.

             

            It worked well for us.

             

            Dennis Todd

             


            From: Ken Schwaber [mailto:ken.schwaber@...]
            Sent: Thursday, February 26, 2004 6:49 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: RE: [scrumdevelopment] Length of Iteration

             

            Two wseek Sprints are training wheels. Who would have thought it.
            Ken
            >
            > From: "Mike Cohn" <mike@...>
            > Date: 2004/02/26 Thu PM 06:39:22 CST
            > To: <scrumdevelopment@yahoogroups.com>
            > Subject: RE: [scrumdevelopment] Length of Iteration
            >
            > Ken--
            >
            > I would not recommend changing the name from Sprint (noun and verb) to
            > Create (verb only). The discussions would be too hard and there are many
            > people I've talked to that like the connotations of sprint.
            >
            > Great observation about the best software coming from teams doing 30-day
            > iterations. I'm one who has spoken out in favor of two-week sprints.
            > However, I have to concur with you that the best software I've seen has come
            > out of teams doing four-week sprints. However, I find that I have a harder
            > time getting a new team to handle four-week sprints. The more rapid learning
            > cycle of 2 week sprints serves me much better when introducing Scrum to a
            > team. It also facilitates getting Product Owners to buy into the idea that
            > they can't change their minds during the sprint. If they get used to that
            > with 2 weeks they can later handle it with 4 weeks.
            >
            > So--I'll stick with my approach of starting with 2 week sprints then moving
            > to four when the team (and organization) can handle it. (This typically
            > takes many months.) But--as you often do, you've now explained to me why
            > something works that I've observed but didn't understand. Thanks!
            >
            > --Mike
            >
            > -----Original Message-----
            > From: Ken Schwaber [mailto:ken.schwaber@...]
            > Sent: Thursday, February 26, 2004 5:21 PM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: [scrumdevelopment] Length of Iteration
            >
            > Several weeks ago, I asked what we as a group thought the length of
            > an iteration should be. A surprisingly large number of people
            > preferred one-to-two week iterations. The reasons given mostly had
            > to do with team output. A hard thing about Scrum is that many of the
            > rules in it have been derived empirically. Yes, Scrum is based in
            > empirical process control and relies on frequent inspection and
            > adaptation, but the way it is constructed to do so to optimally
            > build software that is pleasurable to our customers has been derived
            > by trial and error over fourteen years or so. Mary Poppendieck
            > refers to these rules as the "swarm behavior" rules; they are simple
            > rules that create complex, focused behavior similar to that of ants
            > or bees. The problem with this, of course, is that all of this is
            > experiential and empirical rather than mathematically provable or
            > testable. That is our good and bad news.
            > I've noticed over the years that I've been using Scrum that the best
            > software has been built when the Sprints are long enough for the
            > best creativity to come out of the team, regardless of its
            > composition. By best software, I mean great software, not just
            > software that was built with optimized productivity. Examples that
            > pop to mind are the personalization capabilities of Individual's
            > Newspage internet newspaper; as early as 1996 you could customize
            > the news you wanted to be served. Or, IDX's teleradiology product,
            > which allowed the best radiological minds in the world to
            > collaborate real time to produce the best diagnosis. Or, just
            > recently, Primavera's release 4.0, which raises the bar in the whole
            > project management software marketplace. The teams building each of
            > these products had time to let great ideas gestate; they had "slack"
            > to be great. Maybe we should change the name from Sprint, which is
            > more in line with one and two week iterations, to Create.
            > Ken
            >
            >
            >
            >
            > To Post a message, send it to:   scrumdevelopment@...
            > To Unsubscribe, send a blank message to:
            > scrumdevelopment-unsubscribe@...
            > Yahoo! Groups Links
            >
            >
            >

            >
            >
            >
            >
            > To Post a message, send it to:   scrumdevelopment@...
            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
            > Yahoo! Groups Links
            >
            >
            >

            >
            >



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



          • Ron Jeffries
            ... Please provide the data related to sprint length, productivity, and creativity that underlies the empirical determination that one month is best. ;- Ron
            Message 5 of 19 , Feb 26, 2004
            • 0 Attachment
              On Thursday, February 26, 2004, at 7:20:47 PM, Ken Schwaber wrote:

              > A hard thing about Scrum is that many of the
              > rules in it have been derived empirically.

              Please provide the data related to sprint length, productivity, and
              creativity that underlies the empirical determination that one month is
              best. ;->

              Ron Jeffries
              www.XProgramming.com
              One never knows, do one? -- Fats Waller
            • PaulOldfield1@compuserve.com
              (responding to Ken) ... This observation seems to be in accord with the anecdotes I ve been hearing. I think it enables us to add another criterion by which
              Message 6 of 19 , Feb 27, 2004
              • 0 Attachment
                (responding to Ken)

                > I've noticed over the years that I've been using Scrum
                > that the best software has been built when the Sprints
                > are long enough for the best creativity to come out of the
                > team, regardless of its composition.... The teams ... had
                > time to let great ideas gestate; they had "slack" to be
                > great. Maybe we should change the name from Sprint,
                > which is more in line with one and two week iterations, to
                > Create.

                This observation seems to be in accord with the anecdotes
                I've been hearing. I think it enables us to add another
                criterion by which we evaluate projects when deciding how
                to approach them; the scope for / need for creativity.
                Nice idea, Ken.

                I think this might tie in to the velocity / backlog topic on a
                concurrent thread. Velocity would seem to need more
                up-front analysis, to get a better estimate of the stories.
                Perhaps this breaking down into smaller units for purposes
                of better estimation leaves less room for creativity;
                perhaps longer iterations and backlog belong together,
                short iterations and velocity belong together. It would
                be interesting to see what the experienced XP folk say
                to this.


                Paul Oldfield

                ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                www.aptprocess.com

                any opinions expressed herein are not necessarily those of
                Mentors of Cally or the Appropriate Process Movement
                ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
              • Ron Jeffries
                ... This is definitely an interesting idea. It is certainly true that a short iteration keeps the team s attention right on the backlog. It can get to be a
                Message 7 of 19 , Feb 27, 2004
                • 0 Attachment
                  On Friday, February 27, 2004, at 4:33:57 AM, PaulOldfield1@... wrote:

                  > (responding to Ken)

                  >> I've noticed over the years that I've been using Scrum
                  >> that the best software has been built when the Sprints
                  >> are long enough for the best creativity to come out of the
                  >> team, regardless of its composition.... The teams ... had
                  >> time to let great ideas gestate; they had "slack" to be
                  >> great. Maybe we should change the name from Sprint,
                  >> which is more in line with one and two week iterations, to
                  >> Create.

                  > This observation seems to be in accord with the anecdotes
                  > I've been hearing. I think it enables us to add another
                  > criterion by which we evaluate projects when deciding how
                  > to approach them; the scope for / need for creativity.
                  > Nice idea, Ken.

                  This is definitely an interesting idea. It is certainly true that a short
                  iteration keeps the team's attention right on the backlog. It can get to be
                  a grind. I've seen creativity do some wonderful things, and I've seen it
                  get projects cancelled when the focus shifted too far from what people
                  thought they wanted, even if the creative thing would surely have been
                  better.

                  So maybe one even tunes the iteration size as one goes on?

                  I wonder what one would do with velocity. I wonder whether just changing
                  velocity on an XP project would have the same effect, but I suspect
                  lengthening the iteration and reducing the proportional velocity would work
                  better.

                  Ron Jeffries
                  www.XProgramming.com
                  Just because we learned something new today doesn't mean we were
                  frickin' idiots yesterday. -- Chris Morris, possibly paraphrasing someone.
                • Ken Schwaber
                  ouch!
                  Message 8 of 19 , Feb 27, 2004
                  • 0 Attachment
                    ouch!
                    >
                    > From: Ron Jeffries <ronjeffries@...>
                    > Date: 2004/02/26 Thu PM 08:40:30 CST
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: Re: [scrumdevelopment] Length of Iteration
                    >
                    > On Thursday, February 26, 2004, at 7:20:47 PM, Ken Schwaber wrote:
                    >
                    > > A hard thing about Scrum is that many of the
                    > > rules in it have been derived empirically.
                    >
                    > Please provide the data related to sprint length, productivity, and
                    > creativity that underlies the empirical determination that one month is
                    > best. ;->
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > One never knows, do one? -- Fats Waller
                    >
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                  • Ron Jeffries
                    ... But seriously ... you seem to think that you have observed something. Tell us more ... Ron Jeffries www.XProgramming.com Agility is not an inescapable law
                    Message 9 of 19 , Feb 27, 2004
                    • 0 Attachment
                      On Friday, February 27, 2004, at 7:23:33 AM, Ken Schwaber wrote:

                      > ouch!
                      >>
                      >> > A hard thing about Scrum is that many of the
                      >> > rules in it have been derived empirically.
                      >>
                      >> Please provide the data related to sprint length, productivity, and
                      >> creativity that underlies the empirical determination that one month is
                      >> best. ;->

                      But seriously ... you seem to think that you have observed something. Tell
                      us more ...

                      Ron Jeffries
                      www.XProgramming.com
                      Agility is not an inescapable law of purity
                      but a pragmatic principle of effectiveness. -- Marc Hamann
                    • William Wake
                      ... Paul, I m not following what you re saying here. The Sprint product backlogs I ve seen have estimates, at least for the next several months work. In XP,
                      Message 10 of 19 , Feb 27, 2004
                      • 0 Attachment
                        >Velocity would seem to need more
                        >up-front analysis, to get a better estimate of the stories.

                        Paul,
                        I'm not following what you're saying here. The Sprint product backlogs I've
                        seen have estimates, at least for the next several months' work. In XP, the
                        stories get relative estimates (this small thing is 1 point, that sounds
                        like 3 times as much). I don't see that much difference in their scale.

                        >Perhaps this breaking down into smaller units for purposes
                        >of better estimation leaves less room for creativity;
                        >perhaps longer iterations and backlog belong together,
                        >short iterations and velocity belong together.

                        I don't know if the iteration length is the controlling factor. A couple
                        years ago I worked with a team that shipped 2-3 times a week, and since then
                        on some other projects shipping weekly or nearly so. My sense is that
                        "release pressure" has a bigger impact than iteration length; it's harder
                        (but not impossible) to make a bold creative move when you know you have to
                        ship in 2 days.

                        There have been enough conversations about tracking and such in the xp group
                        that I know there are people who get more concerned about velocity and
                        estimates than I do. I don't care if tasks get added or deleted; I'm not
                        bothered if someone tries an experiment that doesn't work out. (I do like to
                        see all known tasks on the board, crossed off when done.)


                        You and Ken are right that the creativity angle is interesting, though.

                        --
                        Bill Wake William.Wake@... www.xp123.com

                        _________________________________________________________________
                        Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer!
                        http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
                      • J. B. Rainsberger
                        ... Don t feel too bad, Ken: many of us find this to be a strength, and not a weakness. ... The most common complaint I have heard about two-week-long
                        Message 11 of 19 , Feb 27, 2004
                        • 0 Attachment
                          Ken Schwaber wrote:

                          > The problem with this, of course, is that all of this is
                          > experiential and empirical rather than mathematically provable or
                          > testable. That is our good and bad news.

                          Don't feel too bad, Ken: many of us find this to be a strength, and not
                          a weakness.

                          > I've noticed over the years that I've been using Scrum that the best
                          > software has been built when the Sprints are long enough for the
                          > best creativity to come out of the team, regardless of its
                          > composition.

                          The most common complaint I have heard about two-week-long iterations
                          comes after doing 12 of them in a row: the monotony gets to some people.
                          The usual suggestion is to break up the flow with the occasional "down
                          week," usually after a 2- or 3-month-long release cycle. Perhaps
                          lengthening the iteration would alleviate this.

                          Still, I find it compelling to keep the iterations shorter to increase
                          the flow of feedback from the customer. Ken, has once-per-month feedback
                          from the customers been sufficient for your teams? Does the feedback
                          naturally happen more frequently? (In other words, do the people
                          voluntarily seek or offer feedback more frequently without the
                          "ceremony" of a release planning meeting?)
                          --
                          J. B. Rainsberger,
                          Diaspar Software Services
                          http://www.diasparsoftware.com :: +1 416 791-8603
                          Let's write software that people understand
                        • Michael D. Hirsch
                          ... I think sprint really gives the wrong impression. The terms sprint and sustainable development seem antithetical. I nominate lap . Lap has more
                          Message 12 of 19 , Feb 27, 2004
                          • 0 Attachment
                            On Thursday 26 February 2004 07:20 pm, Ken Schwaber wrote:
                            > Maybe we should change the name from Sprint, which is
                            > more in line with one and two week iterations, to Create.

                            I think "sprint" really gives the wrong impression. The terms "sprint" and
                            "sustainable development" seem antithetical.

                            I nominate "lap". "Lap" has more of a long distance runing metaphor, rather
                            than rugby. What are the various time periods in rugby called?

                            Michael
                          • PaulOldfield1@compuserve.com
                            (responding to Bill) ... Hmm... that s really a side issue, and not important. I guess what I m saying is that working on bigger chunks of functionality at a
                            Message 13 of 19 , Feb 27, 2004
                            • 0 Attachment
                              (responding to Bill)

                              >> (Paul)
                              >> Velocity would seem to need more
                              >> up-front analysis, to get a better estimate of the stories.

                              > (Bill)
                              > I'm not following what you're saying here. The Sprint product
                              > backlogs I've seen have estimates, at least for the next several
                              > months' work. In XP, the stories get relative estimates (this small
                              > thing is 1 point, that sounds like 3 times as much). I don't see
                              > that much difference in their scale.

                              Hmm... that's really a side issue, and not important.

                              I guess what I'm saying is that working on bigger chunks of
                              functionality at a time might allow more creativity, and there
                              are things that may go along with working with these bigger
                              chunks. Of course, 'bigger chunks' *may* have nothing to
                              do with the perceived creativity effect.

                              >> Perhaps this breaking down into smaller units for purposes
                              >> of better estimation leaves less room for creativity;
                              >> perhaps longer iterations and backlog belong together,
                              >> short iterations and velocity belong together.

                              > I don't know if the iteration length is the controlling factor. A
                              > couple years ago I worked with a team that shipped 2-3
                              > times a week, and since then on some other projects
                              > shipping weekly or nearly so. My sense is that "release
                              > pressure" has a bigger impact than iteration length; it's harder
                              > (but not impossible) to make a bold creative move when you
                              > know you have to ship in 2 days.

                              Okay, we have an alternative hypothesis, perhaps having some
                              "decompression time" (Alistair's nomenclature) is the key
                              factor. Ron's suggestion of trying to cut velocity (without
                              changing iteration length) would make sense if this were the
                              underlying cause.

                              > There have been enough conversations about tracking and
                              > such in the xp group that I know there are people who get more
                              > concerned about velocity and estimates than I do. I don't care
                              > if tasks get added or deleted; I'm not bothered if someone
                              > tries an experiment that doesn't work out. (I do like to see all
                              > known tasks on the board, crossed off when done.)

                              I guess it depends on what sort of relationship you have with
                              whoever holds the purse strings. Again, tracking is a side
                              issue, though.

                              > You and Ken are right that the creativity angle is interesting,
                              > though.

                              How are we to get the data, though? It's interesting that if
                              'decompression time' does make a difference, the
                              occurrence of a weekend break early in the iteration may
                              make a big difference to the outcome of a short iteration!
                              Don't mind me, I'm just thinking aloud...


                              Paul Oldfield

                              ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                              www.aptprocess.com

                              any opinions expressed herein are not necessarily those of
                              Mentors of Cally or the Appropriate Process Movement
                              ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                            • Ken Schwaber
                              The feedback monthly works fine if it is intended to be at the business value level of granularity ... yes, I think that this will have the market impact that
                              Message 14 of 19 , Feb 27, 2004
                              • 0 Attachment
                                The feedback monthly works fine if it is intended to be at the business value level of granularity ... "yes, I think that this will have the market impact that we intend, but let's..." We do the "does it look best this way or that way" within the Sprint.
                                Ken
                                >
                                > From: "J. B. Rainsberger" <jbrains@...>
                                > Date: 2004/02/27 Fri AM 08:48:03 CST
                                > To: scrumdevelopment@yahoogroups.com
                                > Subject: Re: [scrumdevelopment] Length of Iteration
                                >
                                > Ken Schwaber wrote:
                                >
                                > > The problem with this, of course, is that all of this is
                                > > experiential and empirical rather than mathematically provable or
                                > > testable. That is our good and bad news.
                                >
                                > Don't feel too bad, Ken: many of us find this to be a strength, and not
                                > a weakness.
                                >
                                > > I've noticed over the years that I've been using Scrum that the best
                                > > software has been built when the Sprints are long enough for the
                                > > best creativity to come out of the team, regardless of its
                                > > composition.
                                >
                                > The most common complaint I have heard about two-week-long iterations
                                > comes after doing 12 of them in a row: the monotony gets to some people.
                                > The usual suggestion is to break up the flow with the occasional "down
                                > week," usually after a 2- or 3-month-long release cycle. Perhaps
                                > lengthening the iteration would alleviate this.
                                >
                                > Still, I find it compelling to keep the iterations shorter to increase
                                > the flow of feedback from the customer. Ken, has once-per-month feedback
                                > from the customers been sufficient for your teams? Does the feedback
                                > naturally happen more frequently? (In other words, do the people
                                > voluntarily seek or offer feedback more frequently without the
                                > "ceremony" of a release planning meeting?)
                                > --
                                > J. B. Rainsberger,
                                > Diaspar Software Services
                                > http://www.diasparsoftware.com :: +1 416 791-8603
                                > Let's write software that people understand
                                >
                                >
                                >
                                > To Post a message, send it to: scrumdevelopment@...
                                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                              • Ron Jeffries
                                ... Hassles? Riots? I forget ... Ron Jeffries www.XProgramming.com The Great and Powerful Oz has spoken.
                                Message 15 of 19 , Feb 27, 2004
                                • 0 Attachment
                                  On Friday, February 27, 2004, at 10:19:16 AM, Michael D. Hirsch wrote:

                                  > I nominate "lap". "Lap" has more of a long distance runing metaphor, rather
                                  > than rugby. What are the various time periods in rugby called?

                                  Hassles? Riots? I forget ...

                                  Ron Jeffries
                                  www.XProgramming.com
                                  The Great and Powerful Oz has spoken.
                                • Stephen Jacob
                                  ... Riots? Hardly. :) There s a saying (and remember that in this saying, football doesn t mean American football; it means soccer): Football is a
                                  Message 16 of 19 , Feb 27, 2004
                                  • 0 Attachment
                                    On Fri, Feb 27, 2004 at 02:17:40PM -0500, Ron Jeffries wrote:
                                    > Hassles? Riots? I forget ...

                                    Riots? Hardly. :) There's a saying (and remember that in this
                                    saying, "football" doesn't mean American football; it means
                                    soccer):

                                    "Football is a gentlemen's game played by thugs and rugby is
                                    a thugs' game played by gentlemen."

                                    This can also be applied to the fans of the respective sports. :)
                                    (Ok, so not quite true, but I've yet to hear of a riot at a rugby
                                    match).

                                    ... and the real answer is "halves". First half. Second half. No
                                    further sub-divisions. Well, other than ... I think there's
                                    potential extra time to account for time spent on injuries/whatever
                                    (unlike in American football, where the clock stops for a minute or
                                    so every 5 seconds, the clock doesn't stop often in rugby [or
                                    soccer, for that matter]).

                                    Regards,
                                    sj
                                    --
                                    Stephen Jacob | Stephen.Jacob@... | +1 650 381 6051
                                    Nominum, Inc. | http://www.nominum.com/ | "Communication by Name"
                                  • J. B. Rainsberger
                                    ... Understood. When getting answers to does it look good this way or that way, have the answerers always been in the room (or down the hall)? -- J. B.
                                    Message 17 of 19 , Feb 28, 2004
                                    • 0 Attachment
                                      Ken Schwaber wrote:

                                      > The feedback monthly works fine if it is intended to be at the business value level of granularity ... "yes, I think that this will have the market impact that we intend, but let's..." We do the "does it look best this way or that way" within the Sprint.

                                      Understood. When getting answers to "does it look good this way or that
                                      way," have the answerers always been in the room (or down the hall)?
                                      --
                                      J. B. Rainsberger,
                                      Diaspar Software Services
                                      http://www.diasparsoftware.com :: +1 416 791-8603
                                      Let's write software that people understand
                                    • Ken Schwaber
                                      If you can t get it in the room, or you think down the hall is available and useful, then down the hall. It depends on common sense, as guided by the feedback
                                      Message 18 of 19 , Feb 28, 2004
                                      • 0 Attachment
                                        If you can't get it in the room, or you think down the hall is available and
                                        useful, then down the hall. It depends on common sense, as guided by the
                                        feedback at the end of every Sprint.
                                        Ken

                                        -----Original Message-----
                                        From: J. B. Rainsberger [mailto:jbrains@...]
                                        Sent: Saturday, February 28, 2004 7:35 PM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: Re: [scrumdevelopment] Length of Iteration


                                        Ken Schwaber wrote:

                                        > The feedback monthly works fine if it is intended to be at the business
                                        value level of granularity ... "yes, I think that this will have the market
                                        impact that we intend, but let's..." We do the "does it look best this way
                                        or that way" within the Sprint.

                                        Understood. When getting answers to "does it look good this way or that
                                        way," have the answerers always been in the room (or down the hall)?
                                        --
                                        J. B. Rainsberger,
                                        Diaspar Software Services
                                        http://www.diasparsoftware.com :: +1 416 791-8603
                                        Let's write software that people understand



                                        To Post a message, send it to: scrumdevelopment@...
                                        To Unsubscribe, send a blank message to:
                                        scrumdevelopment-unsubscribe@...
                                        Yahoo! Groups Links
                                      • Mike Beedle
                                        Ken: In many cases there is an interacting hierarchy in the customer that helps to balance the day-to-day interaction with the typical month-type interaction
                                        Message 19 of 19 , Feb 28, 2004
                                        • 0 Attachment
                                          Message
                                           
                                          Ken:
                                           
                                          In many cases there is an "interacting hierarchy" in the customer that helps to balance
                                          the day-to-day interaction with the typical month-type interaction with the Product Owner.
                                           
                                          For example, in our case, in the Sprint Review we always have the Product Owner,
                                          typically a C-level executive or VP, that is *paying* and making final approvals for the
                                          development of the software.  (In our case we often work with the "Chief Compliance Officer",
                                          "Chief Privacy Officer", or even the "Chief Operations Officer".)
                                           
                                          But we work day to day with users from the business, subject matter experts, 
                                          analysts working with the business, or business managers (and sometimes even Directors),
                                          that  guide our day to day development with constant feedback through the Sprint.
                                           
                                          Our acceptance testing spans throughout the Sprint and is executed opportunistically.
                                           
                                          This works out really good, because these resources are available at least a few hours,
                                          giving us a chance to make rapid progress.
                                           
                                          By the way, I have always like the month-length Sprints.  To us, this length often allows us to fit
                                          a *substantial contribution* and deal with surprises, while allowing the developers to 
                                          really focus on the task at hand.
                                           
                                          We look at the Sprint Planning Meetings (including the re-evaluation of work), Sprint Review Meetings 
                                          and the processes of Integration, Testing and Release Management as "overhead",
                                          relative to development (
                                          == programming and unit testing) and the rest of the tasks  
                                          required to get a "tested integrated executable release into production (or internal release)"
                                           
                                          - Mike
                                           


                                           
                                          -----Original Message-----
                                          From: Ken Schwaber [mailto:ken.schwaber@...]
                                          Sent: Saturday, February 28, 2004 9:00 PM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: RE: [scrumdevelopment] Length of Iteration

                                          If you can't get it in the room, or you think down the hall is available and
                                          useful, then down the hall. It depends on common sense, as guided by the
                                          feedback at the end of every Sprint.
                                          Ken

                                          -----Original Message-----
                                          From: J. B. Rainsberger [mailto:jbrains@...]
                                          Sent: Saturday, February 28, 2004 7:35 PM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: Re: [scrumdevelopment] Length of Iteration


                                          Ken Schwaber wrote:

                                          > The feedback monthly works fine if it is intended to be at the business
                                          value level of granularity ... "yes, I think that this will have the market
                                          impact that we intend, but let's..." We do the "does it look best this way
                                          or that way" within the Sprint.

                                          Understood. When getting answers to "does it look good this way or that
                                          way," have the answerers always been in the room (or down the hall)?
                                          --
                                          J. B. Rainsberger,
                                          Diaspar Software Services
                                          http://www.diasparsoftware.com :: +1 416 791-8603
                                          Let's write software that people understand



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







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


                                        Your message has been successfully submitted and would be delivered to recipients shortly.