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

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

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