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

Product Backlog estimates

Expand Messages
  • Richard
    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
    Message 1 of 8 , Dec 12, 2010
    • 0 Attachment
      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
    • 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 2 of 8 , Dec 12, 2010
      • 0 Attachment
        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 3 of 8 , Dec 13, 2010
        • 0 Attachment
          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 4 of 8 , Dec 13, 2010
          • 0 Attachment
            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 5 of 8 , Dec 13, 2010
            • 0 Attachment
              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 6 of 8 , Dec 13, 2010
              • 0 Attachment
                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 7 of 8 , Dec 13, 2010
                • 0 Attachment
                  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 8 of 8 , Dec 14, 2010
                  • 0 Attachment
                    >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.