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

39421Re: [scrumdevelopment] Extending a Sprint

Expand Messages
  • Michael Vizdos
    Jun 29, 2009
      I'd recommend having a conversation with the Team and the Product
      Owner to see what makes sense for the Team. Remember part of the
      focus on Scrum and Time Boxing is to make sure people keep a clear
      focus on delivering "done" stuff at the end of each iteration (and you
      can see there is a slippery slope as to when to call a Sprint "Done"
      with "just a little more stuff to do"....). Be aware of what you
      really need!

      Thank you,

      - Mike Vizdos

      Contact Information

      Web: www.implementingscrum.com
      www.michaelvizdos.com
      AOL IM: MikeV Work
      Twitter: www.twitter.com/mvizdos
      Skype: mvizdos


      PS: Come to one of my workshops. Visit michaelvizdos.com/enroll.

      PPS: Visit implementingscrum.com/subscribe. Receive 2 FREE videos.





      On Mon, Jun 29, 2009 at 2:10 PM, Adam Sroka<adam.sroka@...> wrote:
      >
      >
      > The ideal solution would be to release every Sprint coincident with
      > the end of the Sprint. However, there are a number of perfectly valid
      > reasons for having releases on a different schedule. It is possible,
      > however, to have a sort of "internal release" at the end of each
      > Sprint (or more often) and then allow public releases to happen on
      > some other schedule. Many open source projects do this. So does e.g.
      > Microsoft.
      >
      > If the release will fall in the middle of the next Sprint it might
      > make sense to have a shorter sprint to finish the couple of stories.
      > Given the scenario where we are about to start a two-week Sprint but
      > the release is three weeks away, we could:
      >
      > 1) Have three one-week Sprints.
      > 2) Have a two-week Sprint followed by a one-week Sprint followed by
      > the release.
      > 3) Have a single three-week Sprint.
      >
      > IME, number one is the best solution, but number two works sometimes.
      > Number three rarely works. In general it is best to have shorter
      > sprints and it is best to maintain the length of Sprints consistently
      > so that a rhythm can emerge.
      >
      > 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?
      >>
      >>
      >
      >
    • Show all 23 messages in this topic