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

Re: [scrumdevelopment] Sprint Planning Meetings

Expand Messages
  • 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 1 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 2 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.