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

Re: Sprint Planning Meetings

Expand Messages
  • Joe Tenczar
    Maybe you can look at the angle, What does DONE mean? Estimates tend to be closer once the team realizes that design, doc, testing, etc must occur to claim
    Message 1 of 6 , Aug 1, 2005
      Maybe you can look at the angle, "What does 'DONE' mean?"

      Estimates tend to be closer once the team realizes that design, doc,
      testing, etc must occur to claim that the sushimi is "done."



      --- In scrumdevelopment@yahoogroups.com, "catcmb" <cbrunsting@i...>
      wrote:
      > All,
      >
      > I am new to Scrum (I know ... you have all heard that opening line
      > before!) and the team I am on is relatively new to Scrum also. At
      my
      > company we are having some issues with the Sprint Planning meeting
      > and would welcome some suggestions from the rest of you with more
      > experience.
      >
      > The first half of the meeting goes relatively well - we work with
      the
      > Product Owner to select the high priority requirements from the
      > Product Backlog, based on their estimates and the team
      availability.
      > We estimate the Product Backlog in person-days.
      >
      > Then, in the 2nd half of the meeting we go thru and define our
      tasks,
      > with team members helping to define the tasks and making initial
      > estimates in person-hours.
      >
      > The problem comes at the end of the meeting. Our hours in the
      Sprint
      > backlog always seem to come up short from the planning session. I
      > suspect that there are two issues here -- first, we are missing
      > tasks, which we will find as we progress; second, we are poor at
      > actually estimating how long the tasks will really take.
      >
      > Because of this, it looks like we have lots of available time.
      > Team 'gut feel' says we don't. And past sprints bare this out.
      We
      > are starting our 5th sprint and while we are learning more about
      > ourselves as a team each sprint, we have yet to deliver
      *everything*
      > that we commit to. The last sprint we did much better, delivering
      > the high level features that we committed to, but still had to
      make
      > some compromises on the detail of the functionality we delivered.
      >
      > At this point the Product Owner then insists that we add
      additional
      > product backlog items into the Sprint. The team resists.
      A 'strong
      > disagreement' happens and we all leave after a really long day
      > somewhat dissasitified and frustrated.
      >
      > Have you all had this experience too? Any suggestions on how to
      > improve this going forward?
      >
      > Thanks,
      >
      > Cathy
    • Steven Ropa
      Have you considered estimating items based on level of effort rather than time? Try estimating each item based on an arbitrary scale of 1-20. 1 is the
      Message 2 of 6 , Aug 1, 2005

        Have you considered estimating items based on level of effort rather than time?  Try estimating each item based on an arbitrary scale of 1-20.  1 is the equivalent of “hey, its in there” and 20 is “you want *WHAT?* “

         

        Then, when you sign up for tasks in the next sprint, only sign up for as many “points” as you completed last time.

         

        This should eliminate the argument about using up all of the “person hours” in a given sprint.

         

        Steve

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Joe Tenczar
        Sent: Monday, August 01, 2005 11:12 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: Sprint Planning Meetings

         

        Maybe you can look at the angle, "What does 'DONE' mean?"

        Estimates tend to be closer once the team realizes that design, doc,
        testing, etc must occur to claim that the sushimi is "done."



        --- In scrumdevelopment@yahoogroups.com, "catcmb" <cbrunsting@i...>
        wrote:
        > All,
        >
        > I am new to Scrum (I know ... you have all heard that opening line
        > before!) and the team I am on is relatively new to Scrum also.  At
        my
        > company we are having some issues with the Sprint Planning meeting
        > and would welcome some suggestions from the rest of you with more
        > experience.
        >
        > The first half of the meeting goes relatively well - we work with
        the
        > Product Owner to select the high priority requirements from the
        > Product Backlog, based on their estimates and the team
        availability. 
        > We estimate the Product Backlog in person-days.
        >
        > Then, in the 2nd half of the meeting we go thru and define our
        tasks,
        > with team members helping to define the tasks and making initial
        > estimates in person-hours. 
        >
        > The problem comes at the end of the meeting.  Our hours in the
        Sprint
        > backlog always seem to come up short from the planning session.  I
        > suspect that there are two issues here -- first, we are missing
        > tasks, which we will find as we progress; second, we are poor at
        > actually estimating how long the tasks will really take.
        >
        > Because of this, it looks like we have lots of available time. 
        > Team 'gut feel' says we don't.  And past sprints bare this out. 
        We
        > are starting our 5th sprint and while we are learning more about
        > ourselves as a team each sprint, we have yet to deliver
        *everything*
        > that we commit to.  The last sprint we did much better, delivering
        > the high level features that we committed to, but still had to
        make
        > some compromises on the detail of the functionality we delivered.
        >
        > At this point the Product Owner then insists that we add
        additional
        > product backlog items into the Sprint.  The team resists. 
        A 'strong
        > disagreement' happens and we all leave after a really long day
        > somewhat dissasitified and frustrated.
        >
        > Have you all had this experience too?  Any suggestions on how to
        > improve this going forward?
        >
        > Thanks,
        >
        > Cathy



      • Tobias Mayer
        ... I have found that team gut feel is /the/ best estimation measure. Trust it. Insist that your customer trusts it beacause, as you say ... That speaks for
        Message 3 of 6 , Aug 1, 2005
          > it looks like we have lots of available time. 
          > Team 'gut feel' says we don't. 
          I have found that team gut feel is /the/ best estimation measure.  Trust it.  Insist that your customer trusts it beacause, as you say
          > past sprints bare this out. 
          That speaks for itself, I think.
           
          I believe that the numbers (hours, eta's etc) on the task cards should be for the team only, not the customer.  Essentially it is none of the customer's business.  This is not always practiced, but when it isn't, situations like the one you describe arise.  Kick the customer out of the room for the second part of the meeting.  The team has already made it's commitment;  the rest is detail.
           
          In the longer term, you should investigate an estimation technique that allows you to apply size-relative numbers to backlog items.  From this you can calculate the team's velocity - and you will likely find that the velocity closely matches the team's gut feel. 
           
          Tobias


          catcmb <cbrunsting@...> wrote:
          All,

          I am new to Scrum (I know ... you have all heard that opening line
          before!) and the team I am on is relatively new to Scrum also.  At my
          company we are having some issues with the Sprint Planning meeting
          and would welcome some suggestions from the rest of you with more
          experience.

          The first half of the meeting goes relatively well - we work with the
          Product Owner to select the high priority requirements from the
          Product Backlog, based on their estimates and the team availability. 
          We estimate the Product Backlog in person-days.

          Then, in the 2nd half of the meeting we go thru and define our tasks,
          with team members helping to define the tasks and making initial
          estimates in person-hours. 

          The problem comes at the end of the meeting.  Our hours in the Sprint
          backlog always seem to come up short from the planning session.  I
          suspect that there are two issues here -- first, we are missing
          tasks, which we will find as we progress; second, we are poor at
          actually estimating how long the tasks will really take.

          Because of this, it looks like we have lots of available time. 
          Team 'gut feel' says we don't.  And past sprints bare this out.  We
          are starting our 5th sprint and while we are learning more about
          ourselves as a team each sprint, we have yet to deliver *everything*
          that we commit to.  The last sprint we did much better, delivering
          the high level features that we committed to, but still had to make
          some compromises on the detail of the functionality we delivered.

          At this point the Product Owner then insists that we add additional
          product backlog items into the Sprint.  The team resists.  A 'strong
          disagreement' happens and we all leave after a really long day
          somewhat dissasitified and frustrated.

          Have you all had this experience too?  Any suggestions on how to
          improve this going forward?

          Thanks,

          Cathy




        • Mike Cohn
          Hi Cathy-- You need to educate your product owner into understanding that regardless of what you call a pile of work ( 100 hours or 800 hours ) that it is
          Message 4 of 6 , Aug 1, 2005
            Hi Cathy--

            You need to educate your product owner into understanding that regardless of
            what you call a pile of work ("100 hours" or "800 hours") that it is the
            right amount for the team right now. If the team calls it 100 hours and it
            takes 800 to complete then the next time they call something 100 it will
            probably also take 800 to complete. The difference is, as you suggest,
            estimation error, unidentified tasks, and good old corporate overhead
            (meetings, email, etc.). Most teams I find plan between 40-75% or so of
            their day. A large bureaucracy on the low-end; a garage-based startup
            probably even higher. The team's ability to identify tasks and estimate
            accurately affect it as well.

            I take a "commitment-driven" approach to sprint planning. After each product
            backlog item (a user story for my teams) is split into tasks, I have the
            team ask themselves (literally and out loud), "can we commit to this?" They
            are committing to the user story / backlog item not the list of tasks (this
            is important because there are almost certainly missing tasks). At first
            it's probably a dumb question--8 people are on the team and the first story
            may have turned into 30 hours of work. "Of course we can commit!" they say.
            Well, when the work adds up to 200 hours, the question starts (for that
            team) to get harder. At 250, they really think about it. At 300 maybe they
            say "no more."

            The product owner participates and sees all this. She sees how the team
            arrives at their "gut feel" that they are full and she sees them struggling
            with "is this too much? Not enough?" and is usually much more supportive of
            a team that makes it sprint planning commitment in this way.

            For more on sprint planning, you may want to look at
            http://www.mountaingoatsoftware.com/agileplanning/ which has chapters from
            an upcoming book on planning, including a rather long chapter on sprint
            (iteration) planning.

            Regards,
            Mike Cohn
            Author of User Stories Applied for Agile Software Development
            www.mountaingoatsoftware.com




            On 8/1/05 9:46 AM, "catcmb" <cbrunsting@...> wrote:

            > All,
            >
            > I am new to Scrum (I know ... you have all heard that opening line
            > before!) and the team I am on is relatively new to Scrum also. At my
            > company we are having some issues with the Sprint Planning meeting
            > and would welcome some suggestions from the rest of you with more
            > experience.
            >
            > The first half of the meeting goes relatively well - we work with the
            > Product Owner to select the high priority requirements from the
            > Product Backlog, based on their estimates and the team availability.
            > We estimate the Product Backlog in person-days.
            >
            > Then, in the 2nd half of the meeting we go thru and define our tasks,
            > with team members helping to define the tasks and making initial
            > estimates in person-hours.
            >
            > The problem comes at the end of the meeting. Our hours in the Sprint
            > backlog always seem to come up short from the planning session. I
            > suspect that there are two issues here -- first, we are missing
            > tasks, which we will find as we progress; second, we are poor at
            > actually estimating how long the tasks will really take.
            >
            > Because of this, it looks like we have lots of available time.
            > Team 'gut feel' says we don't. And past sprints bare this out. We
            > are starting our 5th sprint and while we are learning more about
            > ourselves as a team each sprint, we have yet to deliver *everything*
            > that we commit to. The last sprint we did much better, delivering
            > the high level features that we committed to, but still had to make
            > some compromises on the detail of the functionality we delivered.
            >
            > At this point the Product Owner then insists that we add additional
            > product backlog items into the Sprint. The team resists. A 'strong
            > disagreement' happens and we all leave after a really long day
            > somewhat dissasitified and frustrated.
            >
            > Have you all had this experience too? Any suggestions on how to
            > improve this going forward?
            >
            > Thanks,
            >
            > Cathy
            >
            >
            >
            >
            >
            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to:
            > scrumdevelopment-unsubscribe@...
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
          • mike.dwyer1@comcast.net
            Cathy: I agree with what Mike is saying, but if you are also facing a product owner that is accostomed to project plans and the like, I have found this to help
            Message 5 of 6 , Aug 2, 2005
              Cathy:
              I agree with what Mike is saying, but if you are also facing a product owner that is accostomed to project plans and the like, I have found this to help put things into perspective and give light to the hidden consumption of resources.
              Build a project plan three months long consisting of nothing but repeatable tasks like staff meetings, department meetings, lunch, breaks, vacations and the like.  Assign each person (including yourself) to each of the tasks you do.  Then use the "Resource Usage" sheet to show how much time is being consumed and what is available for work.  (If you right click in the yellow area of the research usage screen you can select a combination of work, remaining available, and over commit.
               
              Use this as a base line in estimating but make sure that everyone, particularly the Product Owner.  When we did this the impact was significant.
               
              However, it is a gapstop effort,  you need to move to an estimation method like Mike's.
               
              --
              Mike Dwyer

              "I Keep six faithful serving-men
              Who serve me well and true:
              Their names are What and Where and When
              And How and Why and Who." - Kipling
               
              -------------- Original message --------------

              > Hi Cathy--
              >
              > You need to educate your product owner into understanding that regardless of
              > what you call a pile of work ("100 hours" or "800 hours") that it is the
              > right amount for the team right now. If the team calls it 100 hours and it
              > takes 800 to complete then the next time they call something 100 it will
              > probably also take 800 to complete. The difference is, as you suggest,
              > estimation error, unidentified tasks, and good old corporate overhead
              > (meetings, email, etc.). Most teams I find plan between 40-75% or so of
              > their day. A large bureaucracy on the low-end; a garage-based startup
              > probably even higher. The team's ability to identify tasks and estimate
              > accurately affect it as well.
              >
              > I take a "commitment-driven" approach to sprint planning. After each product
              > backlog item (a user story for my teams) is split into tasks, I have the
              > team ask themselves (literally and out loud), "can we commit to this?" They
              > are committing to the user story / backlog item not the list of tasks (this
              > is important because there are almost certainly missing tasks). At first
              > it's probably a dumb question--8 people are on the team and the first story
              > may have turned into 30 hours of work. "Of course we can commit!" they say.
              > Well, when the work adds up to 200 hours, the question starts (for that
              > team) to get harder. At 250, they really think about it. At 300 maybe they
              > say "no more."
              >
              > The product owner participates and sees all this. She sees how the team
              > arrives at their "gut feel" that they are full and she sees them struggling
              > with "is this too much? Not enough?" and is usually much more supportive of
              > a team that makes it sprint planning commitment in this way.
              >
              > For more on sprint planning, you may want to look at
              > http://www.mountaingoatsoftware.com/agileplanning/ which has chapters from
              > an upcoming book on planning, including a rather long chapter on sprint
              > (iteration) planning.
              >
              > Regards,
              > Mike Cohn
              > Author of User Stories Applied for Agile Software Development
              > www.mountaingoatsoftware.com
              >
              >
              >
              >
              > On 8/1/05 9:46 AM, "catcmb" wrote:
              >
              > > All,
              > >
              > > I am new to Scrum (I know ... you have all heard that opening line
              > > before!) and the team I am on is relatively new to Scrum also. At my
              > > company we are having some issues with the Sprint Planning meeting
              > > and would welcome some suggestions from the rest of you with more
              > > experience.
              > >
              > > The first half of the meeting goes relatively well - we work with the
              > > Product Owner to select the high priority requirements from the
              > > Product Backlog, based on their estimates and the team availability.
              > > We estimate the Product Backlog in person-days.
              > >
              > > Then, in the 2nd half of the meeting we go thru and define our tasks,
              > > with team members helping to define the tasks and making initial
              > > estimates in person-hours.
              > >
              > > The problem comes at the end of the meeting. Our hours in the Sprint
              > > backlog always seem to come up short from the planning session. I
              > > suspect that there are two issues here -- first, we are missing
              > > tasks, which we will find as we progress; second, we are poor at
              > > actually estimating how long the tasks will really take.
              > >
              > > Because of this, it looks like we have lots of available time.
              > > Team 'gut feel' says we don't. And past sprints bare this out. We
              > > are starting our 5th sprint and while we are learning more about
              > > ourselves as a team each sprint, we have yet to deliver *everything*
              > > that we commit to. The last sprint we did much better, delivering
              > > the high level features that we committed to, but still had to make
              > > some compromises on the detail of the functionality we delivered.
              > >
              > > At this point the Product Owner then insists that we add additional
              > > product backlog items into the Sprint. The team resists. A 'strong
              > > disagreement' happens and we all leave after a really long day
              > > somewhat dissasitified and frustrated.
              > >
              > > Have you all had this experience too? Any suggestions on how to
              > > improve this going forward?
              > >
              > > Thanks,
              > >
              > > Cathy
              > >
              > >
              > >
              > >
              > >
              > >
              > > To Post a message, send it to: scrumdevelopment@...
              > > To Unsubscribe, send a blank message to:
              > > scrumdevelopment-unsubscribe@...
              > > Yahoo! Groups Links
              > >
              > >
              > >
              > >
              > >
              > >
              >
              >
              >
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to:
              > scrumdevelopment-unsubscribe@...
              > Yahoo! Groups Links
              >
              > <*> To visit your group on the web, go to:
              > http://groups.yahoo.com/group/scrumdevelopment/
              >
              > <*> To unsubscribe from this group, send an email to:
              > scrumdevelopment-unsubscribe@yahoogroups.com
              >
              > <*> Your use of Yahoo! Groups is subject to:
              > http://docs.yahoo.com/info/terms/
              >
              >
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.