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

Re: [scrumdevelopment] Re: Length of sprint planning meetings

Expand Messages
  • srinivas chillara
      Hello Jo,   In my experience with over a dozen teams(Im a coach), I have found following the book reccomendation (8hrs planning for 4 week sprint, 4 hrs
    Message 1 of 12 , Sep 2, 2008
       
      Hello Jo,
       
      In my experience with over a dozen teams(Im a coach), I have found following the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week sprint) works almost perfectly in the vast majority of cases. Spending significantly more time, is wasted effort, and less time results in being foggy and disorganised.
       
      I would say try your best to "go by the book". Then for some reason if that is not satisfactory (via discussions/retrospectives) then think of shortening/lengthening gradually.
      Trying to follow the book is important, most people start customising this without learning the ropes of Scrum, and understanding how it should/can work very well.
       
      cheers
      Srinivas 
      From: hmeftah <hmeftah@...>
      Subject: [scrumdevelopment] Re: Length of sprint planning meetings
      To: scrumdevelopment@yahoogroups.com
      Date: Tuesday, 2 September, 2008, 5:38 PM

      Hi Jo,

      Yes, you're right 2.5 days for estimate it's too long, a couple of
      hours should be the norm.

      1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
      weeks is too long. Most of the time is over-specified, you have to
      inspect and adapt your Sprint as soon possible.
      2) Identify the main story/change/ maintenance/ features of your
      application needs with the Project Owner.
      3) Try to use "playing poker by pair" same as "pair programming" to
      avoid any person willing to be very defensive about tasks duration.
      4) Rotating people for the second round, if there is an odd number of
      people, play as a develop member with the remaining person to get her
      feedback.

      The aim is to get a roughly realistic( not the defensive one ;-))
      estimate, start the first Sprint for having team velocity, and
      improving it ASAP by coaching, supporting individuals daily.

      Good luck
      Herve Meftah



      Add more friends to your messenger and enjoy! Invite them now.
    • Cenk Çivici
      - Make your sprints short so you have less stories to plan and estimate. Planning meeting for a 4 week iteration will probably take 4 times as long compared to
      Message 2 of 12 , Sep 3, 2008
        - Make your sprints short so you have less stories to plan and estimate.
        Planning meeting for a 4 week iteration will probably take 4 times as
        long compared to a 1 week iteration

        - Prepare for the meeting. (dont make decisions before but review the
        cards, analyze dev tasks etc)



        On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
        >
        > Hello Jo,
        >
        > In my experience with over a dozen teams(Im a coach), I have found following
        > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
        > sprint) works almost perfectly in the vast majority of cases. Spending
        > significantly more time, is wasted effort, and less time results in being
        > foggy and disorganised.
        >
        > I would say try your best to "go by the book". Then for some reason if that
        > is not satisfactory (via discussions/retrospectives) then think of
        > shortening/lengthening gradually.
        > Trying to follow the book is important, most people start customising this
        > without learning the ropes of Scrum, and understanding how it should/can
        > work very well.
        >
        > cheers
        > Srinivas
        >
        > From: hmeftah <hmeftah@...>
        > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
        > To: scrumdevelopment@yahoogroups.com
        > Date: Tuesday, 2 September, 2008, 5:38 PM
        >
        > Hi Jo,
        >
        > Yes, you're right 2.5 days for estimate it's too long, a couple of
        > hours should be the norm.
        >
        > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
        > weeks is too long. Most of the time is over-specified, you have to
        > inspect and adapt your Sprint as soon possible.
        > 2) Identify the main story/change/ maintenance/ features of your
        > application needs with the Project Owner.
        > 3) Try to use "playing poker by pair" same as "pair programming" to
        > avoid any person willing to be very defensive about tasks duration.
        > 4) Rotating people for the second round, if there is an odd number of
        > people, play as a develop member with the remaining person to get her
        > feedback.
        >
        > The aim is to get a roughly realistic( not the defensive one ;-))
        > estimate, start the first Sprint for having team velocity, and
        > improving it ASAP by coaching, supporting individuals daily.
        >
        > Good luck
        > Herve Meftah
        >
        >
        > ________________________________
        > Add more friends to your messenger and enjoy! Invite them now.
        >
      • Cenk Çivici
        - Spending significantly more time, is wasted effort, and less time results in being foggy and disorganised 4 hours is too long. Our meetings are usually 1-3
        Message 3 of 12 , Sep 3, 2008
          - Spending significantly more time, is wasted effort, and less time
          results in being foggy and disorganised

          4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
          iteration.
          Can you explain why you think spending less than 4 hours results in
          being foggy or disorganised?



          On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
          >
          > Hello Jo,
          >
          > In my experience with over a dozen teams(Im a coach), I have found following
          > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
          > sprint) works almost perfectly in the vast majority of cases. Spending
          > significantly more time, is wasted effort, and less time results in being
          > foggy and disorganised.
          >
          > I would say try your best to "go by the book". Then for some reason if that
          > is not satisfactory (via discussions/retrospectives) then think of
          > shortening/lengthening gradually.
          > Trying to follow the book is important, most people start customising this
          > without learning the ropes of Scrum, and understanding how it should/can
          > work very well.
          >
          > cheers
          > Srinivas
          >
          > From: hmeftah <hmeftah@...>
          > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
          > To: scrumdevelopment@yahoogroups.com
          > Date: Tuesday, 2 September, 2008, 5:38 PM
          >
          > Hi Jo,
          >
          > Yes, you're right 2.5 days for estimate it's too long, a couple of
          > hours should be the norm.
          >
          > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
          > weeks is too long. Most of the time is over-specified, you have to
          > inspect and adapt your Sprint as soon possible.
          > 2) Identify the main story/change/ maintenance/ features of your
          > application needs with the Project Owner.
          > 3) Try to use "playing poker by pair" same as "pair programming" to
          > avoid any person willing to be very defensive about tasks duration.
          > 4) Rotating people for the second round, if there is an odd number of
          > people, play as a develop member with the remaining person to get her
          > feedback.
          >
          > The aim is to get a roughly realistic( not the defensive one ;-))
          > estimate, start the first Sprint for having team velocity, and
          > improving it ASAP by coaching, supporting individuals daily.
          >
          > Good luck
          > Herve Meftah
          >
          >
          > ________________________________
          > Add more friends to your messenger and enjoy! Invite them now.
          >
        • chuckspublicprofile
          I don t know that a 1 week iteration is the answer -- that s a pretty extreme change, I would move more conservatively to a 2 week iteration and see how that
          Message 4 of 12 , Sep 3, 2008
            I don't know that a 1 week iteration is the answer -- that's a pretty
            extreme change, I would move more conservatively to a 2 week iteration
            and see how that works first.

            We do the SPM in two phases:

            Phase 1 -- Size stories and establish point budget
            1. PO presents backlog one item at a time.
            2. Devs get small amount of time to ask questions, Discussion round 1.
            3. Devs size via planning poker round 1
            4. Outlier estimates get their short say. Discussion round 2.
            5. Devs size via planning poker round 2
            6. Either have ScrumMaster make exec decision (pref not) or ask if
            the outliers can live with a more average estimate.
            7. Once you've sized enough stories to fill the sprint budget and
            possibly some stretch, end this part of the meeting.

            If Steps 2-6 seem to drag on, you need a way of quickening the
            process. I call this a "collision" or "decision" strategy. Examples
            from roughly slowest to roughly fastest.
            1. Team makes unanimous decision.
            2. Certain team members indicate that they can "live with" a
            different estimate... (See "Fist of Five" for similar strategy)
            3. Timebox of each discussion round.
            4. Toss out outliers and take average.
            5. Use Mean, Median, or Mode of all estimates.
            6. ScrumMaster makes exec decision
            7. Team Lead/Sr. Architect/dev makes exec decision

            One could argue that there are more than the above strategies (I
            welcome additions), and I think one could also argue that some of the
            strategies above are better/worse for the team long term. Ideally you
            want to move your team to #1 or2, but if time gets in the way, I
            recommend using 3-7 until you can get to #1 or 2.

            Phase one for a 2 week sprint takes us about 1 hour.

            Phase 2
            Devs task out each story one at a time for all stories in this sprint
            and in the stretch work. If this process begins to take too long, we
            try to finish at least half the work in the SPM, and then schedule a
            VERY quick follow up meeting to task the rest.

            Phase 2 for a 2 week sprint usually takes us 1-3 hours (depending on
            if we use pre-tasked stretch work leftover from a previous iteration)

            We have a working agreement that we can still change point estimates
            during the SPM, but we almost NEVER do it at the follow up meeting.
            This gives folks an incentive to get through the SPM on time.

            Charles Bradley
            CSM, SCJP


            --- In scrumdevelopment@yahoogroups.com, "Cenk Çivici"
            <cenk.civici@...> wrote:
            >
            > - Make your sprints short so you have less stories to plan and estimate.
            > Planning meeting for a 4 week iteration will probably take 4 times as
            > long compared to a 1 week iteration
            >
            > - Prepare for the meeting. (dont make decisions before but review the
            > cards, analyze dev tasks etc)
            >
            >
            >
            > On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
            > >
            > > Hello Jo,
            > >
            > > In my experience with over a dozen teams(Im a coach), I have found
            following
            > > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs
            for a 2 week
            > > sprint) works almost perfectly in the vast majority of cases. Spending
            > > significantly more time, is wasted effort, and less time results
            in being
            > > foggy and disorganised.
            > >
            > > I would say try your best to "go by the book". Then for some
            reason if that
            > > is not satisfactory (via discussions/retrospectives) then think of
            > > shortening/lengthening gradually.
            > > Trying to follow the book is important, most people start
            customising this
            > > without learning the ropes of Scrum, and understanding how it
            should/can
            > > work very well.
            > >
            > > cheers
            > > Srinivas
            > >
            > > From: hmeftah <hmeftah@...>
            > > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
            > > To: scrumdevelopment@yahoogroups.com
            > > Date: Tuesday, 2 September, 2008, 5:38 PM
            > >
            > > Hi Jo,
            > >
            > > Yes, you're right 2.5 days for estimate it's too long, a couple of
            > > hours should be the norm.
            > >
            > > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
            > > weeks is too long. Most of the time is over-specified, you have to
            > > inspect and adapt your Sprint as soon possible.
            > > 2) Identify the main story/change/ maintenance/ features of your
            > > application needs with the Project Owner.
            > > 3) Try to use "playing poker by pair" same as "pair programming" to
            > > avoid any person willing to be very defensive about tasks duration.
            > > 4) Rotating people for the second round, if there is an odd number of
            > > people, play as a develop member with the remaining person to get her
            > > feedback.
            > >
            > > The aim is to get a roughly realistic( not the defensive one ;-))
            > > estimate, start the first Sprint for having team velocity, and
            > > improving it ASAP by coaching, supporting individuals daily.
            > >
            > > Good luck
            > > Herve Meftah
            > >
            > >
            > > ________________________________
            > > Add more friends to your messenger and enjoy! Invite them now.
            > >
            >
          • srinivas chillara
            4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week iteration. Can you explain why you think spending less than 4 hours results in being
            Message 5 of 12 , Sep 3, 2008
              "4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
              iteration.
              Can you explain why you think spending less than 4 hours results in
              being foggy or disorganised?"


              Well, it is simply an emperical observation (over a couple of years and many teams), and felt the book reccomendation worked really well. 4 hrs for a 2 weeks were usually required, especially if close to zero pre-planning activity.


              So I can't really explain why 4 hrs is the right duration for a SPM.
              What I can tell is: what usually happens when teams try to do the SPM in 3 hrs or less. They take about 2.5 hrs to understand the product backlog, discuss and agree upon the number of items to commit. Then they hurridly do the task breakdown for the commitment. THey usually don't do a cross-check if they can actually meet the commitment, and leave no time for any meaningful negotiation with the PO. Actually in most cases, in a 2 to 3 sprints they realise this (during retros) and go for hte 4 hrs.

              cheers
              Srinivas





              Did you know? You can CHAT without downloading messenger. Go to http://in.webmessenger.yahoo.com/
            • srinivas chillara
              This is not to say that 4 hrs should not be revised upwards or down, but simply to mean that the teams should really try hard to make do 4 hrs, and with
              Message 6 of 12 , Sep 3, 2008
                This is not to say that 4 hrs should not be revised upwards or down, but simply to mean that the teams should really try hard to make do 4 hrs, and with experience change the duration of the SPM.
                Srinivas

                --- On Wed, 3/9/08, Cenk Çivici <cenk.civici@...> wrote:
                From: Cenk Çivici <cenk.civici@...>
                Subject: Re: [scrumdevelopment] Re: Length of sprint planning meetings
                To: scrumdevelopment@yahoogroups.com
                Date: Wednesday, 3 September, 2008, 8:54 PM

                - Spending significantly more time, is wasted effort, and less time
                results in being foggy and disorganised

                4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
                iteration.
                Can you explain why you think spending less than 4 hours results in
                being foggy or disorganised?

                On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@yahoo. co.in> wrote:
                >
                > Hello Jo,
                >
                > In my experience with over a dozen teams(Im a coach), I have found following
                > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
                > sprint) works almost perfectly in the vast majority of cases. Spending
                > significantly more time, is wasted effort, and less time results in being
                > foggy and disorganised.
                >
                > I would say try your best to "go by the book". Then for some reason if that
                > is not satisfactory (via discussions/ retrospectives) then think of
                > shortening/lengthen ing gradually.
                > Trying to follow the book is important, most people start customising this
                > without learning the ropes of Scrum, and understanding how it should/can
                > work very well.
                >
                > cheers
                > Srinivas
                >
                > From: hmeftah <hmeftah@yahoo. com>
                > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                > To: scrumdevelopment@ yahoogroups. com
                > Date: Tuesday, 2 September, 2008, 5:38 PM
                >
                > Hi Jo,
                >
                > Yes, you're right 2.5 days for estimate it's too long, a couple of
                > hours should be the norm.
                >
                > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                > weeks is too long. Most of the time is over-specified, you have to
                > inspect and adapt your Sprint as soon possible.
                > 2) Identify the main story/change/ maintenance/ features of your
                > application needs with the Project Owner.
                > 3) Try to use "playing poker by pair" same as "pair programming" to
                > avoid any person willing to be very defensive about tasks duration.
                > 4) Rotating people for the second round, if there is an odd number of
                > people, play as a develop member with the remaining person to get her
                > feedback.
                >
                > The aim is to get a roughly realistic( not the defensive one ;-))
                > estimate, start the first Sprint for having team velocity, and
                > improving it ASAP by coaching, supporting individuals daily.
                >
                > Good luck
                > Herve Meftah
                >
                >
                > ____________ _________ _________ __
                > Add more friends to your messenger and enjoy! Invite them now.
                >


                Unlimited freedom, unlimited storage. Get it now
              Your message has been successfully submitted and would be delivered to recipients shortly.