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

Re: [scrumdevelopment] Extending a Sprint

Expand Messages
  • George Dinwiddie
    ... 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
    Message 1 of 23 , Jun 29, 2009
      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
      ----------------------------------------------------------------------
    • 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 2 of 23 , Jun 29, 2009
        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 3 of 23 , Jun 29, 2009
          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 4 of 23 , Jun 29, 2009
            >
            > 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 5 of 23 , Jun 29, 2009
              >
              > 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 6 of 23 , Jun 29, 2009
                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 7 of 23 , Jun 29, 2009
                  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 8 of 23 , Jun 29, 2009
                    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 9 of 23 , Jun 29, 2009
                      > 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 10 of 23 , Jun 29, 2009
                        >
                        > 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 11 of 23 , Jun 29, 2009
                          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 12 of 23 , Jun 29, 2009
                            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 13 of 23 , Jun 30, 2009
                              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 14 of 23 , Jun 30, 2009
                                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 15 of 23 , Jun 30, 2009
                                  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 16 of 23 , Jul 1, 2009
                                    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 17 of 23 , Jul 1, 2009
                                      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 18 of 23 , Jul 1, 2009
                                        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 19 of 23 , Jul 1, 2009
                                          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.