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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.