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

RE: [scrumdevelopment] Product Backlog estimates

Expand Messages
  • Roy Morien
    I would think that the next time the team meets to consider the backlog, for the purpose of selecting stories into the Sprint Backlog, would be a good time for
    Message 1 of 8 , Dec 12, 2010
      I would think that the next time the team meets to consider the backlog, for the purpose of selecting stories into the Sprint Backlog, would be a good time for the Product Owner to introduce the new stories, giving them a priority, and opening the meeting for estimates. If the new story is of high priority, and likely to be selected for the next forthcoming sprint, then a more detailed analysis and estimate would be done, Other stories that would be deferred to a later sprint would have a gross estimate done, for the purpose of an overall view of the likely project completion date, and detailed at a later time.

      It doesn't matter, I would suggest, what estimating method you use, provided you feel it has been sufficiently successful in your situation, previously.

      I see noe reason why the Product Owner might not do a bit of work on the story to get more insight, before the meeting, so the group members can be briefed reasonably when the story is introduced.

      Regards,
      Roy Morien


      To: scrumdevelopment@yahoogroups.com
      From: rdahl@...
      Date: Mon, 13 Dec 2010 05:09:49 +0000
      Subject: [scrumdevelopment] Product Backlog estimates

       
      I was wondering what the appropriate mechanism is for keeping a product backlog "estimated" when new ideas are added to it? If we use the Fibonacci numbers for easy, medium and hard, when is the appropriate time to update those with the new items that are added?

      Thanks for the insight.

      Rick


    • David
      We schedule backlog grooming sessions each sprint. Not during sprint planning. Sent from my iPad
      Message 2 of 8 , Dec 13, 2010
        We schedule backlog grooming sessions each sprint. Not during sprint planning. 

        Sent from my iPad

        On Dec 12, 2010, at 11:51 PM, Roy Morien <roymorien@...> wrote:

         

        I would think that the next time the team meets to consider the backlog, for the purpose of selecting stories into the Sprint Backlog, would be a good time for the Product Owner to introduce the new stories, giving them a priority, and opening the meeting for estimates. If the new story is of high priority, and likely to be selected for the next forthcoming sprint, then a more detailed analysis and estimate would be done, Other stories that would be deferred to a later sprint would have a gross estimate done, for the purpose of an overall view of the likely project completion date, and detailed at a later time.

        It doesn't matter, I would suggest, what estimating method you use, provided you feel it has been sufficiently successful in your situation, previously.

        I see noe reason why the Product Owner might not do a bit of work on the story to get more insight, before the meeting, so the group members can be briefed reasonably when the story is introduced.

        Regards,
        Roy Morien


        To: scrumdevelopment@yahoogroups.com
        From: rdahl@...
        Date: Mon, 13 Dec 2010 05:09:49 +0000
        Subject: [scrumdevelopment] Product Backlog estimates

         
        I was wondering what the appropriate mechanism is for keeping a product backlog "estimated" when new ideas are added to it? If we use the Fibonacci numbers for easy, medium and hard, when is the appropriate time to update those with the new items that are added?

        Thanks for the insight.

        Rick


      • David A Barrett
        Keep an eye on what the goal is. The estimates are supposed to help the PO to decide how to prioritise the PB, with the main focus on identifying those items
        Message 3 of 8 , Dec 13, 2010
          Keep an eye on what the goal is.  The estimates are supposed to help the PO to decide how to prioritise the PB, with the main focus on identifying those items that should be added to the next Sprint or two.

          We keep a "Priority Level" field in our PB.  Basically just a 1, 2, 3 or 4.  A "1" is likely to be selected in the next few Sprints, while a "4" is probably some kooky idea that came up in a brainstorming session.  For priority level 1's, we like to have an estimate like 1/2, 1, 2 or 4 days on them.  Priority 1's bigger than that generally need to be broken down into smaller items.  Priorities 2-4 can go with a "small", "large" or "huge" designation until they bubble up closer to the top of the list, when we'll have another look at them for estimating.



          Dave Barrett


          This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

          Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
        • Roy Morien
          I m not quite with you on this one. I would not see an essential correlation between size / complexity, and priority. A small item could be of the highest
          Message 4 of 8 , Dec 13, 2010
            I'm not quite with you on this one. I would not see an essential correlation between size / complexity, and priority. A small item could be of the highest priority, and a big one of the lowest priority. In your scaling, a '4' (kooky idea) would be considered as 'do it, or not', I would think, and if it is considered good enough to do, then decide on priority.

            So, priority is about how important it is, an estimate is about how much, how long, not when.

            Right?

            Regards,
            Roy Morien


            To: scrumdevelopment@yahoogroups.com
            From: dave.barrett@...
            Date: Mon, 13 Dec 2010 10:49:03 -0500
            Subject: [scrumdevelopment] Re: Product Backlog estimates

             
            Keep an eye on what the goal is.  The estimates are supposed to help the PO to decide how to prioritise the PB, with the main focus on identifying those items that should be added to the next Sprint or two.

            We keep a "Priority Level" field in our PB.  Basically just a 1, 2, 3 or 4.  A "1" is likely to be selected in the next few Sprints, while a "4" is probably some kooky idea that came up in a brainstorming session.  For priority level 1's, we like to have an estimate like 1/2, 1, 2 or 4 days on them.  Priority 1's bigger than that generally need to be broken down into smaller items.  Priorities 2-4 can go with a "small", "large" or "huge" designation until they bubble up closer to the top of the list, when we'll have another look at them for estimating.



            Dave Barrett


            This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

            Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.

          • Ron Jeffries
            Hello, Roy. Absolutely right. Often the hardest things are also the least useful. On Monday, December 13, 2010, at 8:11:24 PM, you ... Ron Jeffries
            Message 5 of 8 , Dec 13, 2010
              Hello, Roy.

              Absolutely right. Often the hardest things are also the least
              useful.

              On Monday, December 13, 2010, at 8:11:24 PM, you
              wrote:

              > I'm not quite with you on this one. I would not see an essential
              > correlation between size / complexity, and priority. A small item
              > could be of the highest priority, and a big one of the lowest
              > priority. In your scaling, a '4' (kooky idea) would be considered
              > as 'do it, or not', I would think, and if it is considered good
              > enough to do, then decide on priority.

              > So, priority is about how important it is, an estimate is about how much, how long, not when.



              Ron Jeffries
              www.XProgramming.com
              Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
              of his head. It is, as far as he knows, the only way of coming downstairs,
              but sometimes he feels that there really is another way, if only he could
              stop bumping for a moment and think of it. And then he feels that perhaps
              there isn't. -- A. A. Milne
            • Roy Morien
              I suggested that the Product Owner might do some work on new stories to go in the backlog before the meeting. Given that Product Backlog grooming is
              Message 6 of 8 , Dec 13, 2010
                I suggested that the Product Owner might do some work on new stories to go in the backlog before the meeting. Given that Product Backlog grooming is essentially a Product Owner responsibility, do you see any disadvantage in that, and in the team discussing new stories intrioduced by the Product Owner when they are discussing the sprint plan?
                 
                Regards,
                Roy Morien
                 

                CC: scrumdevelopment@yahoogroups.com
                To: scrumdevelopment@yahoogroups.com
                From: davidakoontz@...
                Date: Mon, 13 Dec 2010 06:10:48 -0600
                Subject: Re: [scrumdevelopment] Product Backlog estimates

                 
                We schedule backlog grooming sessions each sprint. Not during sprint planning. 

                Sent from my iPad

                On Dec 12, 2010, at 11:51 PM, Roy Morien <roymorien@...> wrote:

                 

                I would think that the next time the team meets to consider the backlog, for the purpose of selecting stories into the Sprint Backlog, would be a good time for the Product Owner to introduce the new stories, giving them a priority, and opening the meeting for estimates. If the new story is of high priority, and likely to be selected for the next forthcoming sprint, then a more detailed analysis and estimate would be done, Other stories that would be deferred to a later sprint would have a gross estimate done, for the purpose of an overall view of the likely project completion date, and detailed at a later time.

                It doesn't matter, I would suggest, what estimating method you use, provided you feel it has been sufficiently successful in your situation, previously.

                I see noe reason why the Product Owner might not do a bit of work on the story to get more insight, before the meeting, so the group members can be briefed reasonably when the story is introduced.

                Regards,
                Roy Morien



                To: scrumdevelopment@yahoogroups.com
                From: rdahl@...
                Date: Mon, 13 Dec 2010 05:09:49 +0000
                Subject: [scrumdevelopment] Product Backlog estimates

                 
                I was wondering what the appropriate mechanism is for keeping a product backlog "estimated" when new ideas are added to it? If we use the Fibonacci numbers for easy, medium and hard, when is the appropriate time to update those with the new items that are added?

                Thanks for the insight.

                Rick




              • David A Barrett
                ... how long, not when. Not quite. Priority is about how important it is relative to its cost (effort to develop). We ve had cases when the PO has selected
                Message 7 of 8 , Dec 14, 2010
                  >So, priority is about how important it is, an estimate is about how much, how long, not when.

                  Not quite.  Priority is about how important it is relative to its cost (effort to develop).  We've had cases when the PO has selected several smaller, less important items, over a single bigger items simply because the cumulative benefit of the smaller ones was what they wanted now.

                  But I was really talking about how much effort should be put into estimating any particular PB item.  My experience has been that most developers can come up with a tiny/bigger/huge decision within a few seconds of hearing about any PB item.  That's good enough if the PB item is low down on importance.   Once people start talking about doing something in the near future, then you'll need to move towards a more precise estimate.

                  The whole point being that the PO needs enough information to be able to prioritise, so the estimates need to have the right amount of precision to them at the right time.  That's the only criteria that really counts when you're deciding when to get the estimating done.  


                  Dave Barrett


                  This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                  Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                Your message has been successfully submitted and would be delivered to recipients shortly.