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

RE: [scrumdevelopment] Length of sprint planning meetings

Expand Messages
  • Jo Newcombe Cook
    Hi Ron I like your suggestion about the face down estimates... I might suggest that we try that. So you are suggesting that we estimate the stories as a whole?
    Message 1 of 12 , Sep 1, 2008
    • 0 Attachment
      Hi Ron
       
      I like your suggestion about the face down estimates... I might suggest that we try that.
       
      So you are suggesting that we estimate the stories as a whole? Right now we break the stories down into tasks and estimate those. If we don't break down the stories into tasks during planning, when would we do this? Prior to starting to implement the story?
       
      Regards,
      Jo
       

    • Sarath Kummamuru
      Hi Jo, Planning poker and story points work well when they are used to estimate user stories as a whole with the whole team estimating them. From what i see
      Message 2 of 12 , Sep 2, 2008
      • 0 Attachment
        Hi Jo,
            Planning poker and story points work well when they are used to estimate user stories as a whole with the whole team estimating them.

           From what i see you said you were estimating the tasks as user stories, with can get very intensive as you said.

           The normal mechanism that has worked for me is that we have teams estimate the user stories in story points before they start any of their sprints and once in a while when new stories are added during the sprints in a particular release. Not for each task.

           The sprint planning session should basically be a design discussion and design decisions meeting that allows the whole team to understand the design goals (ui, high level and may be low level design, test case design, etc).

           The tasks for the sprint should be derived from the design discussion and can be estimated in hours by any one who thinks they are competent to complete the task and if there is any major disagreement with the estimate the team can have a time boxed discussion to discuss the task estimate. (But this should be pretty quick). One thing to remember is that the tasks estimates are only estimates to drive the sprint goal and sprint burn down to indicate to the team the amount of work involved.

        These are not to be taken as commitments and that is some thing you might want to keep in mind to get your team to time box estimation discussions.

        thanks,
        Sarath.

        On Tue, Sep 2, 2008 at 11:04 AM, Jo Newcombe Cook <jo@...> wrote:

        Hi Ron
         
        I like your suggestion about the face down estimates... I might suggest that we try that.
         
        So you are suggesting that we estimate the stories as a whole? Right now we break the stories down into tasks and estimate those. If we don't break down the stories into tasks during planning, when would we do this? Prior to starting to implement the story?
         
        Regards,
        Jo
         


      • hmeftah
        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
        Message 3 of 12 , Sep 2, 2008
        • 0 Attachment
          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
        • Ron Jeffries
          Hello, Jo. On Tuesday, September 2, 2008, at 1:34:52 AM, you ... Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put
          Message 4 of 12 , Sep 2, 2008
          • 0 Attachment
            Hello, Jo. On Tuesday, September 2, 2008, at 1:34:52 AM, you
            wrote:

            > So you are suggesting that we estimate the stories as a whole? Right now
            > we break the stories down into tasks and estimate those. If we don't
            > break down the stories into tasks during planning, when would we do
            > this? Prior to starting to implement the story?

            Well, first of all, tasks are teh suck. Breaking the job up into
            tasks means you have to put it back together, which is always
            difficult. I'm writing a Kate chapter about that right now.

            What I recommend is this:

            1. Product owner writes story on whiteboard, explains it.
            2. Developers /briefly/ brainstorm and list technical steps needed,
            (like tasks but not going to be done as tasks nor tracked).
            3. Repeat until enough stories are on board.
            4. Look at the list, draw the line where you can accomplish all
            above the line.
            5. Commit.
            6. Do stories as a unit, not broken into tasks.
            Burn stories, not tasks.

            Q: But for this to work, everyone would have to be able to work on
            everything.
            A: Yes, that would be ideal. And you could do pair programming --
            that would fill in needed skills and people would learn as well.

            Q: But even so, for this to work, stories would have to be very
            small.
            A: Yes.

            Hmm. Time to blog that.

            Ron Jeffries
            www.XProgramming.com
            I have tried in my way to be free. -- Leonard Cohen
          • 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 5 of 12 , Sep 2, 2008
            • 0 Attachment
               
              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 6 of 12 , Sep 3, 2008
              • 0 Attachment
                - 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 7 of 12 , Sep 3, 2008
                • 0 Attachment
                  - 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 8 of 12 , Sep 3, 2008
                  • 0 Attachment
                    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 9 of 12 , Sep 3, 2008
                    • 0 Attachment
                      "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 10 of 12 , Sep 3, 2008
                      • 0 Attachment
                        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.