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

Re: [scrumdevelopment] Summation of user story points to epic l evel point estimation

Expand Messages
  • steveropa
    I think the second bit is just the second of two options: one being have the stories add up to the epic number, which feels very artificial to me, and two
    Message 1 of 10 , Jul 9, 2013
    • 0 Attachment
      I think the second bit is just the second of two options:  one being have the stories add up to the epic number, which feels very artificial to me, and two being there is a difference between the epic estimate and the sum of the stories. 
       
      I’m with you Kurt, the answer is no, they don’t need to add up to the epic point estimation.  For that matter, I would trust estimate that did add up like that even less than I already do trust estimates, which is not at all.
       
      Steve
      From: Kurt Häusler
      Sent: ‎Tuesday‎, ‎July‎ ‎9‎, ‎2013 ‎11‎:‎07‎ ‎PM
      To: scrumdevelopment@yahoogroups.com
       
       


      On 10 Jul 2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

      > The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

      The answer to the first bit is no. I don't quite understand the second bit.

    • Markus Gärtner
      Hi Pooja, it s ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a
      Message 2 of 10 , Jul 10, 2013
      • 0 Attachment
        Hi Pooja,

        it's ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a sprint for a particular epic might be less or more than the original estimated points for the epics. Statistically they will balance out in the long run.

        Best Markus

        --
        Dipl.-Inform. Markus Gärtner
        Author of ATDD by Example - A Practical Guide to Acceptance
        Test-Driven Development

        On 10.07.2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

        HI,
        During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

        Regards,
        Pooja




        ------------------------------------

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/scrumdevelopment/join
           (Yahoo! ID required)

        <*> To change settings via email:
           scrumdevelopment-digest@yahoogroups.com
           scrumdevelopment-fullfeatured@yahoogroups.com

        <*> 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/

      • Madhur Kathuria
        In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to
        Message 3 of 10 , Jul 10, 2013
        • 0 Attachment
          In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to create similar confusions

          What we have tried to do for some of our teams to have separate notion of relative estimations at Epic(epic points) and Story(story points) levels. This has helped the POs most as they can still track the progress and give a high level release plan without pushing the teams to estimate early or trying to superimpose estimations at higher level to better estimations done by team at story level

          Will be happy to share more information about this in the group in case it makes any sense to the team members on this list.

          With Regards,
          Madhur Kathuia, Certified Scrum Coach
          Chair, India Scrum Enthusiasts Community (ISEC)
          Founder, Agile Pune
           
          Call: +91.8506011150
          Skype: madhur.kathuria


          On 10 July 2013 10:24, poojawandile <poojawandile@...> wrote:
           

          HI,
          During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

          Regards,
          Pooja


        • Prashant Pund
          Story points are relative measures. Expecting Epic=Σ Stories is making them absolute measures. Stories are not arithmetic decomposition of epics. Most often
          Message 4 of 10 , Jul 10, 2013
          • 0 Attachment

            Story points are relative measures. Expecting Epic=Σ Stories is making them absolute measures. Stories are not arithmetic decomposition of epics. Most often than not, there will be difference between the epic size and sum of story points.
            Prashant Pund
            Agile Coach
            AgileSoft Methodologies

            On Jul 10, 2013 12:44 PM, "Markus Gärtner" <mgaertne@...> wrote:
             

            Hi Pooja,

            it's ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a sprint for a particular epic might be less or more than the original estimated points for the epics. Statistically they will balance out in the long run.

            Best Markus

            --
            Dipl.-Inform. Markus Gärtner
            Author of ATDD by Example - A Practical Guide to Acceptance
            Test-Driven Development

            On 10.07.2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

            HI,
            During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

            Regards,
            Pooja




            ------------------------------------

            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

            <*> To visit your group on the web, go to:
               http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
               Individual Email | Traditional

            <*> To change settings online go to:
               http://groups.yahoo.com/group/scrumdevelopment/join
               (Yahoo! ID required)

            <*> To change settings via email:
               scrumdevelopment-digest@yahoogroups.com
               scrumdevelopment-fullfeatured@yahoogroups.com

            <*> 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/

          • Sekhar
            Madhur, Can you please give more insights on this estimation ? Thanks Sekhar On Wed, Jul 10, 2013 at 12:55 PM, Madhur Kathuria
            Message 5 of 10 , Jul 10, 2013
            • 0 Attachment
              Madhur,

              Can you please give more insights on this estimation ?

              Thanks
              Sekhar


              On Wed, Jul 10, 2013 at 12:55 PM, Madhur Kathuria <madhur.kathuria@...> wrote:
               

              In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to create similar confusions

              What we have tried to do for some of our teams to have separate notion of relative estimations at Epic(epic points) and Story(story points) levels. This has helped the POs most as they can still track the progress and give a high level release plan without pushing the teams to estimate early or trying to superimpose estimations at higher level to better estimations done by team at story level

              Will be happy to share more information about this in the group in case it makes any sense to the team members on this list.

              With Regards,
              Madhur Kathuia, Certified Scrum Coach
              Chair, India Scrum Enthusiasts Community (ISEC)
              Founder, Agile Pune
              Skype: madhur.kathuria


              On 10 July 2013 10:24, poojawandile <poojawandile@...> wrote:
               

              HI,
              During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

              Regards,
              Pooja



            • George Dinwiddie
              Pooja, ... To further what others have said, I suggest not even using the same point scale for your epics and your small stories. Before refining the epics
              Message 6 of 10 , Jul 10, 2013
              • 0 Attachment
                Pooja,

                On 7/10/13 12:54 AM, poojawandile wrote:
                > HI,
                > During one of our discussions, the point related to story point
                > estimation at epic and user story level came up. During release
                > planning, the product owner usually define Epics which are then
                > further sliced into smaller user stories at the product backlog
                > grooming meetings. The epics are normally large in size and estimated
                > at 13 points and above and the stories are sliced such that each
                > story is not more than 8 points. Each epic can have multiple user
                > stories. The question is, is it necessary that the point estimation
                > at the user story level should add up to epic point estimation? Or it
                > is OK to have smaller variation in points at epic/story level?

                To further what others have said, I suggest not even using the same
                point scale for your epics and your small stories. Before refining the
                epics into stories, there is no mathematical precision to them.

                I prefer using T-shirt sizes (small, medium, large) for epics so that
                people are less tempted to do math on the unknown. Over time, you can
                collect data on how many story points were actually completed for
                various size epics. This will give you numerical ranges for plotting
                predictions. (See
                http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/)
                You're not tied to a particular number, though, and if you see that the
                size of a "medium" has drifted over time, you can project with what you
                feel is the more realistic range.

                - George

                --
                Want to speak at AgileDC October 8, 2013? http://agiledc.org/speak/
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • David A Barrett
                Resist strongly the urge to do anything involving story-point math. Story-point math is a smell that you re missing the point. Story-points (and estimates in
                Message 7 of 10 , Jul 10, 2013
                • 0 Attachment
                  Resist strongly the urge to do anything involving story-point math.  Story-point math is a smell that you're missing the point.

                  Story-points (and estimates in general) are a somewhat useful tool for selecting the right amount of work to put into a Sprint.  They also have some utility for getting a ballpark idea of how many Sprints an epic might take.  But this idea breaks down the bigger an epic gets - kind of a Hiesenberg Uncertainty Principle for Scrum  and when you get past that point you're virtually doing Waterfall again.

                  What I would expect to see happen, if everything is proceeding normally, is that the number of User Stories that made up an epic would change over the course of working on an epic and that the estimates for many of those User Stories would also change.  This would reflect the feedback that the both the programmers and the users are putting into the backlog as they project progresses, and if it doesn't happen, then you're probably doing something wrong.

                  So the idea of adding up the story-points in the constituent parts of an epic and comparing them to the story points assigned to the epic is probably only feasible in a really small epic, but in that case the "big picture" planning aspect about the epic (ie:  is it going to take 6 Sprints or 10 Sprints to finish?) is negligible.



                  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.
                • Adam Sroka
                  ... Story-point math is a smell that you re missing the point. ... Absolutely. The main problem with story points is that they are a pseudo-mathematical
                  Message 8 of 10 , Jul 10, 2013
                  • 0 Attachment


                    On Jul 10, 2013 3:28 PM, "David A Barrett" <dave.barrett@...> wrote:
                    >
                    >  
                    >
                    > Resist strongly the urge to do anything involving story-point math.  Story-point math is a smell that you're missing the point.
                    >

                    Absolutely. The main problem with story points is that they are a pseudo-mathematical concept that for some reason encourages people to compound estimation errors with elaborate arithmetic. 

                    The other problem with story points is that for some reason they enable people to accept stories that are larger than the smallest valuable slice they are capable of delivering. 

                  Your message has been successfully submitted and would be delivered to recipients shortly.