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

Re: [scrumdevelopment] Re: Extending a Sprint

Expand Messages
  • Adam Sroka
    If there is a good reason understood and agreed to by all, then it makes sense. However, forcing it onto the team to meet some arbitrary deadline (Which
    Message 1 of 23 , Jun 30, 2009
    • 0 Attachment
      If there is a "good reason" understood and agreed to by all, then it
      makes sense. However, forcing it onto the team to meet some arbitrary
      deadline (Which releases are - as often as not) is clearly a violation
      of the relationship between the team and the business. It is the
      business' right to specify what is to be delivered and in what
      order-of-priority. It is the team's right to work at a pace that is
      livable and sustainable.

      On Tue, Jun 30, 2009 at 7:17 AM, jmilunsky<jack@...> wrote:
      >
      >
      > This should be a one off type of thing. I agree that it's a slippery slope.
      > We did this once in 9 months. So I would avoid it under normal
      > circumstances.
      >
      > But this scenario seemed to me like one in which you could make an allowance
      > as it was right at the end of the release cycle or so it seemed.
      >
      > But if the release cycle is every couple months then doing this every couple
      > months is probably not a good idea.
      >
      > --- In scrumdevelopment@yahoogroups.com, "Michael Spayd" <michael@...>
      > wrote:
      >>
      >> My general position is to not extend Sprints, to follow the timebox quite
      >> religiously because it drives the wrong team behavior, of "oh if we have
      >> just a few more days we can get this other thing done, or we didn't quite
      >> get this done, so just give us some more time and . . ." If you don't like
      >> those rules, don't do Scrum, do Kanban.
      >>
      >> For those who suggested extending the length by a few days, or do
      >> different Sprint lengths, I have a question:
      >>
      >> what if you had a team with a few members who asked to do this same thing
      >> (extend the Sprint) every second Sprint because they were on a monthly
      >> release cycle and this always happened? (I ask because, knowing some inside
      >> information about the question posed, this is what in fact has happened).
      >> Would you make the same recommendation, or a different one?
      >>
      >> Regards,
      >>
      >>
      >> Michael
      >>
      >>
      >> --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@> wrote:
      >> >
      >> > >
      >> > > My suggestion is that you lavishly pay your developers for overtime.
      >> > > Buy a case of red bull, keep the pizza delivery company on speed dial,
      >> > > provide sleeping bags for the office, and have a turbo session for the
      >> > > last
      >> > > few days of the sprint. You can get away with 20 hour work days, if
      >> > > your
      >> > > team is willing.
      >> > >
      >> > > Make sure they're willing due to incentives.
      >> > >
      >> > > Just my opinion...
      >> > >
      >> > I am not sure if this is sarcastic or not. Is that what you really
      >> > think?
      >> >
      >> > Carlton
      >> >
      >>
      >
      >
    • Jim Schiel
      I strongly recommend against extending a Sprint. This has little to do with forcing anything upon the team and much more to do with getting to DONE and
      Message 2 of 23 , Jul 1, 2009
      • 0 Attachment
        I strongly recommend against extending a Sprint. This has little to do with forcing anything upon the team and much more to do with getting to DONE and maintaining the value of the Scrum team's time. Bottom line -- when a Sprint ends is an arbitrary point in time at which the team stops, looks at what they completed, and decides what to do next. If the incomplete items are still the most important things to be done, they'll be picked up and finished in the next Sprint. 

        When teams start looking at the end of the Sprint as the end of the coding effort (until, of course, the final Sprint), they begin undesirable behaviors like trying to squish a bunch of work into the last couple days of the Sprint. That's where corners, and quality, gets cuts. Teams needs to work at their highest sustainable pace all the time, and not try to cram at the end. If they complain that they only need another day, the response from the Scrum Master should be, "Fine. You'll get that day right after the next Sprint Planning." No harm, no foul, folks. The end of a Sprint is that and no more -- the end of the Sprint. 

        Jim Schiel
        Owner/CEO, Artisan Software Consulting LLC
        Agile Coach, CST

         
        On Jun 30, 2009, at 11:55 PM, Adam Sroka wrote:



        If there is a "good reason" understood and agreed to by all, then it
        makes sense. However, forcing it onto the team to meet some arbitrary
        deadline (Which releases are - as often as not) is clearly a violation
        of the relationship between the team and the business. It is the
        business' right to specify what is to be delivered and in what
        order-of-priority. It is the team's right to work at a pace that is
        livable and sustainable.

        On Tue, Jun 30, 2009 at 7:17 AM, jmilunsky<jack@brightspark3. com> wrote:
        >
        >
        > This should be a one off type of thing. I agree that it's a slippery slope.
        > We did this once in 9 months. So I would avoid it under normal
        > circumstances.
        >
        > But this scenario seemed to me like one in which you could make an allowance
        > as it was right at the end of the release cycle or so it seemed.
        >
        > But if the release cycle is every couple months then doing this every couple
        > months is probably not a good idea.
        >
        > --- In scrumdevelopment@ yahoogroups. com, "Michael Spayd" <michael@... >
        > wrote:
        >>
        >> My general position is to not extend Sprints, to follow the timebox quite
        >> religiously because it drives the wrong team behavior, of "oh if we have
        >> just a few more days we can get this other thing done, or we didn't quite
        >> get this done, so just give us some more time and . . ." If you don't like
        >> those rules, don't do Scrum, do Kanban.
        >>
        >> For those who suggested extending the length by a few days, or do
        >> different Sprint lengths, I have a question:
        >>
        >> what if you had a team with a few members who asked to do this same thing
        >> (extend the Sprint) every second Sprint because they were on a monthly
        >> release cycle and this always happened? (I ask because, knowing some inside
        >> information about the question posed, this is what in fact has happened).
        >> Would you make the same recommendation, or a different one?
        >>
        >> Regards,
        >>
        >>
        >> Michael
        >>
        >>
        >> --- In scrumdevelopment@ yahoogroups. com, "banshee858" <cnett858@> wrote:
        >> >
        >> > >
        >> > > My suggestion is that you lavishly pay your developers for overtime.
        >> > > Buy a case of red bull, keep the pizza delivery company on speed dial,
        >> > > provide sleeping bags for the office, and have a turbo session for the
        >> > > last
        >> > > few days of the sprint. You can get away with 20 hour work days, if
        >> > > your
        >> > > team is willing.
        >> > >
        >> > > Make sure they're willing due to incentives.
        >> > >
        >> > > Just my opinion...
        >> > >
        >> > I am not sure if this is sarcastic or not. Is that what you really
        >> > think?
        >> >
        >> > Carlton
        >> >
        >>
        >
        > 


      • George Dinwiddie
        ... BTW, I ve seen teams do certain stories at the beginning of the sprint, taking them to done-done to meet a mid-sprint release, and then continuing with the
        Message 3 of 23 , Jul 1, 2009
        • 0 Attachment
          Jim Schiel wrote:
          >
          >
          > I strongly recommend against extending a Sprint. This has little to do
          > with forcing anything upon the team and much more to do with getting to
          > DONE and maintaining the value of the Scrum team's time. Bottom line --
          > when a Sprint ends is an arbitrary point in time at which the team
          > stops, looks at what they completed, and decides what to do next. If the
          > incomplete items are still the most important things to be done, they'll
          > be picked up and finished in the next Sprint.

          BTW, I've seen teams do certain stories at the beginning of the sprint,
          taking them to done-done to meet a mid-sprint release, and then
          continuing with the rest of the stories in the sprint. It causes a
          little extra work, but came out pretty well.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Michael James
          ... This is how I recall handling this while on a Scrum dev team. Acceptance criteria included Deployed/released on x date , where x is within the Sprint. I
          Message 4 of 23 , Jul 1, 2009
          • 0 Attachment
            On Jul 1, 2009, at 9:47 AM, George Dinwiddie wrote:
            > BTW, I've seen teams do certain stories at the beginning of the
            > sprint,
            > taking them to done-done to meet a mid-sprint release, and then
            > continuing with the rest of the stories in the sprint. It causes a
            > little extra work, but came out pretty well.

            This is how I recall handling this while on a Scrum dev team.
            Acceptance criteria included "Deployed/released on x date", where x is
            within the Sprint. I don't recall it causing any real problem. This
            would allow the Sprint duration to stay constant.

            --mj
            .
            . An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
            .
          • Ron Jeffries
            ... Per a chat with Chet: I would not at all recommend extending a Sprint while in the middle of it. I m much less troubled by saying This next Sprint will be
            Message 5 of 23 , Jul 1, 2009
            • 0 Attachment
              Hello, Jim. On Wednesday, July 1, 2009, at 11:45:39 AM, you wrote:

              > I strongly recommend against extending a Sprint.

              Per a chat with Chet: I would not at all recommend extending a
              Sprint while in the middle of it. I'm much less troubled by saying
              "This next Sprint will be N days long because <some external
              event>".

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              If another does not intend offense, it is wrong for me to seek it;
              if another does indeed intend offense, it is foolish for me to permit it.
              -- Kelly Easterley
            Your message has been successfully submitted and would be delivered to recipients shortly.