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

Sprint Planning Meetings

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