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

RE: [scrumdevelopment] Re: Sprint Planning Meetings

Expand Messages
  • 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 1 of 6 , Aug 1, 2005
    • 0 Attachment

      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 2 of 6 , Aug 1, 2005
      • 0 Attachment
        > 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 3 of 6 , Aug 1, 2005
        • 0 Attachment
          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 4 of 6 , Aug 2, 2005
          • 0 Attachment
            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.