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

Re: [scrumdevelopment] Re: Extending a Sprint

Expand Messages
  • 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 1 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 2 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 3 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.