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

Re: [scrumdevelopment] Release dates mid-sprint

Expand Messages
  • Chris Brookins
    Thanks George - that is sound advice - seems we need to bite the bullet. Sounds like until the release dates that the CEO chooses align with our optimum 3 week
    Message 1 of 7 , Oct 4, 2008
      Thanks George - that is sound advice - seems we need to bite the bullet.  Sounds like until the release dates that the CEO chooses align with our optimum 3 week iterations we'll need to occasionally hold 1 week iterations that do align.  The result will be the teams will get a feel for two different velocities - a 1 week and a 3 week.  Maybe that isn't so bad. 

      On Sat, Oct 4, 2008 at 3:06 PM, George Dinwiddie <lists@...> wrote:

      Chris Brookins wrote:
      > I find our company sometimes choose release dates that are part-way
      > through our sprint (not always, but once every 2-4 sprints). We do 3
      > weeks sprints because our definition of done and capacity requires it,

      I would revisit this decision. Try making the stories smaller.


      > and I do not want to change iteration length to match the end of the
      > release for all of the usual reasons (by doing so we will get
      > inconsistent velocity numbers, the teams will lose a feel for what they
      > can do within a std iteration, the company and teams will forget when we
      > start and stop an iteration so they can be around for reviews,
      > retrospectives, and planning days, etc)
      >
      > To accommodate a sprint with a release date in the middle, the teams do
      > an abbreviated planning session at the beginning of the Sprint to meet
      > the release date, then plan more work after the release date. e.g. they
      > act as if the 3 week sprint was 2 mini sprints but without the
      > retrospective, review, etc at the end of the release date. And of
      > course our burn down graph looks like a saw tooth or mountain range.

      Hmmm... It seems to me that you experience all the things you fear from
      a non-standard iteration when you release in the middle of the
      iteration, too. I would just bite the bullet and have a short iteration
      leading up to the release date. Then start a normal size iteration
      after that.

      - George

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


    • Petri Heiramo
      Hi, That s an interesting situations you re in. :) ... iterations ... Why not just ignore the velocity on the sprints that don t match the 3 week standard? If
      Message 2 of 7 , Oct 5, 2008
        Hi,


        That's an interesting situations you're in. :)

        > Sounds like until the release dates that the CEO chooses align with our
        > optimum 3 week iterations we'll need to occasionally hold 1 week
        iterations
        > that do align. The result will be the teams will get a feel for two
        > different velocities - a 1 week and a 3 week. Maybe that isn't so bad.

        Why not just ignore the velocity on the sprints that don't match the 3
        week standard? If the dates are chosen at random, there is no
        knowledge of how long the "release sprint" will be. You'll end up
        doing a bit of juggling with the numbers, and that doesn't help
        increasing the accuracy of that value.

        If the team has good practice, they should already be pretty good at
        selecting themselves the right amount of work for the short sprints,
        and don't need a separate velocity value for that.

        How many normal sprints do you have for one abnormal one?


        Yours Sincerely,


        Petri Heiramo
        Senior Process Improvement Manager, CSP
        Digia Plc., Finland
      • chuckspublicprofile
        We have the same issue. Our current strategy on that is that we just create a story to represent the activities involved in a release, and we estimate it and
        Message 3 of 7 , Oct 6, 2008
          We have the same issue.

          Our current strategy on that is that we just create a story to
          represent the activities involved in a release, and we estimate it and
          task it like any other story.

          As has been said before, not ideal, but we find it useful.

          Charles Bradley


          --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
          <petri.heiramo@...> wrote:
          >
          > Hi,
          >
          >
          > That's an interesting situations you're in. :)
          >
          > > Sounds like until the release dates that the CEO chooses align
          with our
          > > optimum 3 week iterations we'll need to occasionally hold 1 week
          > iterations
          > > that do align. The result will be the teams will get a feel for two
          > > different velocities - a 1 week and a 3 week. Maybe that isn't so
          bad.
          >
          > Why not just ignore the velocity on the sprints that don't match the 3
          > week standard? If the dates are chosen at random, there is no
          > knowledge of how long the "release sprint" will be. You'll end up
          > doing a bit of juggling with the numbers, and that doesn't help
          > increasing the accuracy of that value.
          >
          > If the team has good practice, they should already be pretty good at
          > selecting themselves the right amount of work for the short sprints,
          > and don't need a separate velocity value for that.
          >
          > How many normal sprints do you have for one abnormal one?
          >
          >
          > Yours Sincerely,
          >
          >
          > Petri Heiramo
          > Senior Process Improvement Manager, CSP
          > Digia Plc., Finland
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.