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

Re: [scrumdevelopment] Sprint Planning Meetings

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