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

Re: [scrumdevelopment] Release dates mid-sprint

Expand Messages
  • Chris Brookins
    ... accordingly? The CEO is picking the dates based on gut feel of what would be the right date before any stories are planned and the sprint durations or
    Message 1 of 7 , Oct 4, 2008
      >> Is there a reason why the company is not planning the releases accordingly?
      The CEO is picking the dates based on gut feel of what would be the right date before any stories are planned and the sprint durations or dates are considered  - e.g. he is enthusiastic a release planning decision matrix where the date is always fixed, the quality is firm, and the features delivered are flexible. 

      >> I have a feeling that the release dates are what is controlling your releases. Is that correct?
      That is correct - I am trying to get us into a different place - I am working with our CEO to get him to at least pick dates aligned with end of iteration. 

      On Sat, Oct 4, 2008 at 3:00 PM, Robert Dempsey <robertonrails@...> wrote:

      Hi Chris,

      Is there a reason why the company is not planning the releases accordingly? Generally, we look at what features need to go into a release, estimate stories, look at the required number of sprints, and plan from there. The releases are based on features rather than solid dates. I have a feeling that the release dates are what is controlling your releases. Is that correct?

      Sincerely,  

      Robert Dempsey
      http://www.agiledevelopmentwithscrum.com

    • 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 2 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 3 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 4 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.