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

Re: Extending a Sprint

Expand Messages
  • jmilunsky
    My feeling on this is under normal circumstances don t change sprint lengths but if the team is all in agreement and you feel that if the Sprint is extended
    Message 1 of 23 , Jun 29, 2009
    • 0 Attachment
      My feeling on this is under normal circumstances don't change sprint lengths but if the team is all in agreement and you feel that if the Sprint is extended you can manage the additional story load - then I say go for it. The caveat being that the team controls the decision.


      --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
      >
      > allisonweiss wrote:
      > > I promised a team member I would submit his question (limited yahoo
      > > group access here):
      > >
      > > We have an upcoming release date and our sprint ends several days
      > > before the release. Is it OK for us as a team to agree during
      > > planning to extent this sprint several days to allow a few extra high
      > > value stories to make it into the release? The only other
      > > alternative would be to have these stories wait 1 month for the next
      > > release date. Which is more valuable in the SCRUM process the
      > > software delivered to production or maintaining sprint durations at
      > > fixed 2 week intervals?
      >
      > You've gotten some good suggestions. Here's one more:
      >
      > Do your normal 2-week sprint. Then do the additional stories for the
      > release in a pure "pull" process, with only one story in progress at a
      > time. I suspect you'll maximize the amount of work that's done-done in
      > that way.
      >
      > - George
      >
      > --
      > ----------------------------------------------------------------------
      > * George Dinwiddie * http://blog.gdinwiddie.com
      > Software Development http://www.idiacomputing.com
      > Consultant and Coach http://www.agilemaryland.org
      > ----------------------------------------------------------------------
      >
    • Jacob Ozolins
      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
      Message 2 of 23 , Jun 29, 2009
      • 0 Attachment
        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...


        On Mon, Jun 29, 2009 at 10:22 PM, George Dinwiddie <lists@...> wrote:


        allisonweiss wrote:
        > I promised a team member I would submit his question (limited yahoo
        > group access here):
        >
        > We have an upcoming release date and our sprint ends several days
        > before the release. Is it OK for us as a team to agree during
        > planning to extent this sprint several days to allow a few extra high
        > value stories to make it into the release? The only other
        > alternative would be to have these stories wait 1 month for the next
        > release date. Which is more valuable in the SCRUM process the
        > software delivered to production or maintaining sprint durations at
        > fixed 2 week intervals?

        You've gotten some good suggestions. Here's one more:

        Do your normal 2-week sprint. Then do the additional stories for the
        release in a pure "pull" process, with only one story in progress at a
        time. I suspect you'll maximize the amount of work that's done-done in
        that way.

        - George

        --
        ----------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------


      • banshee858
        ... I am not sure if this is sarcastic or not. Is that what you really think? Carlton
        Message 3 of 23 , Jun 29, 2009
        • 0 Attachment
          >
          > 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
        • banshee858
          ... Well, we are not talking about Christmas shopping, we are talking about satisfying the customer on an important release with high valued stories. Perhaps
          Message 4 of 23 , Jun 29, 2009
          • 0 Attachment
            >
            > No. Nein. Wrong. Negatory.
            > Do you get a couple of extra days to finish your christmas shopping? Pay your taxes?
            >
            Well, we are not talking about Christmas shopping, we are talking about satisfying the customer on an important release with high valued stories. Perhaps the kind of stories that will build goodwill and trust with the customer? It might make sense to consider doing these.

            And you can get an extension to pay your taxes, you just have to pay a penalty. Maybe in this situation the penalty is worth paying? Maybe not. There are too many variables we do not know just to issue a blanket statement that it should never be done. I agree it is suspicious and risky, but I would not say its "wrong".

            How are people supposed to learn if they are never allowed to make a mistake? IMO, the risk is low (a few days) and the reward has the potential high to be high if we control scope and follow our standard practices. It could be a good opportunity to learn something about why we do not extend Sprints. Or it could be a way to learn strategies to do this successfully in the rare instances we are asked to.

            Carlton
          • Michael Spayd
            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
            Message 5 of 23 , Jun 29, 2009
            • 0 Attachment
              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
              >
            • daswartz@prodigy
              Hello Michael, Hmmm. In that case, I d likely suggest going to weekly sprints all-around. ... -- Doug Swartz
              Message 6 of 23 , Jun 29, 2009
              • 0 Attachment
                Hello Michael,

                Hmmm. In that case, I'd likely suggest going to weekly sprints
                all-around.

                Monday, June 29, 2009, 10:56:49 PM, you 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?


                --
                Doug Swartz
              • Alan Dayley
                What are the benefits your company and team have experienced because of the time box? Are the expected benefits of this one time extension worth the risk of
                Message 7 of 23 , Jun 29, 2009
                • 0 Attachment
                  What are the benefits your company and team have experienced because
                  of the time box?

                  Are the expected benefits of this "one time" extension worth the risk
                  of weakening those benefits by opening the door to time box to
                  changes?

                  What are the benefits to the team and company for having a regular
                  rhythm of start and end? Are you willing to risk these?

                  Is your team well disciplined and and experienced in Scrum? Where are
                  you on the "shu-ha-ri" (http://martinfowler.com/bliki/ShuHaRi.html)
                  path of Scrum and agile practices?

                  The most simple questions are: Why is the release date not on a sprint
                  ending date? What problems does this disconnection cause?

                  Alan

                  On Mon, Jun 29, 2009 at 10:36 AM,
                  allisonweiss<aweiss@...> wrote:
                  >
                  >
                  > I promised a team member I would submit his question (limited yahoo group
                  > access here):
                  >
                  > We have an upcoming release date and our sprint ends several days before the
                  > release. Is it OK for us as a team to agree during planning to extent this
                  > sprint several days to allow a few extra high value stories to make it into
                  > the release? The only other alternative would be to have these stories wait
                  > 1 month for the next release date. Which is more valuable in the SCRUM
                  > process the software delivered to production or maintaining sprint durations
                  > at fixed 2 week intervals?
                  >
                  >
                • Tobias Mayer
                  ... release date not on a sprint ending date? Indeed. The stringent time-boxing requirement of Scrum is there for a reason. It surfaces organizational
                  Message 8 of 23 , Jun 29, 2009
                  • 0 Attachment
                    > Why is the release date not on a sprint ending date?

                    Indeed.  The stringent time-boxing requirement of Scrum is there for a reason.  It surfaces organizational impediments and dysfunction.  Extending a sprint when things don't align will simply bury the problem again.

                    If you extend a sprint once it is likely you'll do so again.  And again.  And you'll continually fail to use the opportunities presented to you to improve the way you work.  Don't take this one to the team, just stick with the framework.  It's simpler.

                    Tobias

                  • banshee858
                    ... The timebox is important, but its just a tool. In some circumstances, because we are intelligent, thinking, rationale human beings, we select different
                    Message 9 of 23 , Jun 29, 2009
                    • 0 Attachment
                      >
                      > 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.
                      >
                      The timebox is important, but its just a tool. In some circumstances, because we are intelligent, thinking, rationale human beings, we select different tools because the circumstance are different.
                      >
                      > For those who suggested extending the length by a few days, or do different Sprint
                      > lengths, I have a question:
                      >
                      FWIW, I was not.

                      >
                      > 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?
                      >
                      That was not the question that was posed by the OP. If that question was posed, then I would not allow the Sprint to be extended because it is pretty clear the Team has not mastered selecting the right amount of work to fit in the timebox that is the correct priority, yet.

                      Carlton
                    • allisonweiss
                      Thanks for the answers so far. In this case, the Scrum Master (me) held the team to the rules. But as our insider points out, this is a frequent question
                      Message 10 of 23 , Jun 29, 2009
                      • 0 Attachment
                        Thanks for the answers so far. In this case, the Scrum Master (me) held the team to the rules. But as our insider points out, this is a frequent question from the team (err..at least one or two members). They have been together as a Scrum team for about ten months. Rule violations (or boundary stretching) are common suggestions/questions. Your input here will help with future decision making when these come up.


                        Some of you have suggested we should release on the last day of the sprint. We release two days after the end of the sprint for a couple of reasons. Primarily, we find ourselves working to the very end of the sprint. If a story doesn't make it, we haven't packaged its code up into the release. On average, we release every two sprints. There are also some organizational rules about what days we can release. Is this something we should reconsider?



                        --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
                        >
                        > What are the benefits your company and team have experienced because
                        > of the time box?
                        >
                        > Are the expected benefits of this "one time" extension worth the risk
                        > of weakening those benefits by opening the door to time box to
                        > changes?
                        >
                        > What are the benefits to the team and company for having a regular
                        > rhythm of start and end? Are you willing to risk these?
                        >
                        > Is your team well disciplined and and experienced in Scrum? Where are
                        > you on the "shu-ha-ri" (http://martinfowler.com/bliki/ShuHaRi.html)
                        > path of Scrum and agile practices?
                        >
                        > The most simple questions are: Why is the release date not on a sprint
                        > ending date? What problems does this disconnection cause?
                        >
                        > Alan
                        >
                        > On Mon, Jun 29, 2009 at 10:36 AM,
                        > allisonweiss<aweiss@...> wrote:
                        > >
                        > >
                        > > I promised a team member I would submit his question (limited yahoo group
                        > > access here):
                        > >
                        > > We have an upcoming release date and our sprint ends several days before the
                        > > release. Is it OK for us as a team to agree during planning to extent this
                        > > sprint several days to allow a few extra high value stories to make it into
                        > > the release? The only other alternative would be to have these stories wait
                        > > 1 month for the next release date. Which is more valuable in the SCRUM
                        > > process the software delivered to production or maintaining sprint durations
                        > > at fixed 2 week intervals?
                        > >
                        > >
                        >
                      • Ron Jeffries
                        Hello, Tobias. On Tuesday, June 30, 2009, at 1:06:45 AM, you ... Yes, and ... Sprints used to BE a month. and ... Having sprints of 14 days then 17, then 14
                        Message 11 of 23 , Jun 29, 2009
                        • 0 Attachment
                          Hello, Tobias. On Tuesday, June 30, 2009, at 1:06:45 AM, you
                          wrote:

                          > Indeed. The stringent time-boxing requirement of Scrum is there
                          > for a reason. It surfaces organizational impediments and
                          > dysfunction. Extending a sprint when things don't align will simply bury the problem again.

                          > If you extend a sprint once it is likely you'll do so again. And
                          > again. And you'll continually fail to use the opportunities
                          > presented to you to improve the way you work. Don't take this one
                          > to the team, just stick with the framework. It's simpler.

                          Yes, and ...

                          Sprints used to BE a month.

                          and ...

                          Having sprints of 14 days then 17, then 14 then 14,
                          then 14 then 17, then 14 then 16, then 14 then 17, i.e. filling
                          out the month each time,

                          doesn't seem to me to be breaking the timebox in the sense of
                          "extending".

                          And ... if this team is so good that they don't need a stabilization
                          kind of Sprint, and can actually do a few stories DONE DONE in the
                          extra couple of days, maybe there isn't a big problem.

                          And ... if the team's velocity is stable, stretching the iteration
                          won't really do anything but bring a couple of stories forward one
                          release, once, which isn't going to impact total value delivered
                          much at all.

                          And ... if their quality is that good, why not just release at (or
                          two days after) the end of every Sprint, instead of on a monthly
                          basis.

                          And ... I'd like to visit them and see if they're really that good.
                          It could be that this is a sensible extension of a really good team
                          that for some good reasons really needs or wants a one-month release
                          cycle and a short Sprint. Or it could be a more average team just
                          messing around while there's some really interesting impediment
                          waiting to be removed that would make them go twice as fast as they
                          are.

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          Just because XP doesn't talk about how to make fire, should we assume it
                          requires us to use sticks? -- Richard MacDonald
                        • jmilunsky
                          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
                          Message 12 of 23 , Jun 30, 2009
                          • 0 Attachment
                            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
                            > >
                            >
                          • Gary Moore
                            I m of the opinion that quality would suffer dramatically with an approach like this. Code written at 2am most definitely will be of less quality than code
                            Message 13 of 23 , Jun 30, 2009
                            • 0 Attachment
                              I'm of the opinion that quality would suffer dramatically with an approach like this. Code written at 2am most definitely will be of less quality than code written at 2pm.

                              I do agree that Sprint length should not change once the Team and PO have established the duration that makes sense for them and their business. Keeping up the same pace has it's advantages as mentioned earlier.

                              Cheers,

                              --Gary




                              --- In scrumdevelopment@yahoogroups.com, Jacob Ozolins <j.ozolins@...> 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...
                              >
                              >
                              > On Mon, Jun 29, 2009 at 10:22 PM, George Dinwiddie
                              > <lists@...>wrote:
                              >
                              > >
                              > >
                              > > allisonweiss wrote:
                              > > > I promised a team member I would submit his question (limited yahoo
                              > > > group access here):
                              > > >
                              > > > We have an upcoming release date and our sprint ends several days
                              > > > before the release. Is it OK for us as a team to agree during
                              > > > planning to extent this sprint several days to allow a few extra high
                              > > > value stories to make it into the release? The only other
                              > > > alternative would be to have these stories wait 1 month for the next
                              > > > release date. Which is more valuable in the SCRUM process the
                              > > > software delivered to production or maintaining sprint durations at
                              > > > fixed 2 week intervals?
                              > >
                              > > You've gotten some good suggestions. Here's one more:
                              > >
                              > > Do your normal 2-week sprint. Then do the additional stories for the
                              > > release in a pure "pull" process, with only one story in progress at a
                              > > time. I suspect you'll maximize the amount of work that's done-done in
                              > > that way.
                              > >
                              > > - George
                              > >
                              > > --
                              > > ----------------------------------------------------------
                              > > * George Dinwiddie * http://blog.gdinwiddie.com
                              > > Software Development http://www.idiacomputing.com
                              > > Consultant and Coach http://www.agilemaryland.org
                              > > ----------------------------------------------------------
                              > >
                              > >
                              > >
                              >
                            • 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 14 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 15 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 16 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 17 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 18 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.