Story Points flaw?












4















Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.





Our team is fairly new to them and trying to figure out how to best apply them?



Here' the problem, per sprint;




  • A developer who is dealing with small tickets and requests might complete;



250 x XXS (1) = 250





  • The same developer who is working on a large feature might complete;



1 x XL (20) = 20




How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.





Our sizing chart (Fibonacci-ish)



| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |
|------|------|------|------|------|------|------|------|------|
| 1 | 2 | 3 | 5 | 8 | 13 | 20 | 30 | 50 |




Related:




  • Why use both story points and hours?

  • Story Points to Ideal Days

  • Forecasting Story Points in Agile

  • Alternatives to estimating in hours/story points










share|improve this question




















  • 1





    Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

    – nvoigt
    Feb 14 at 11:07











  • Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

    – Tiago Cardoso
    Feb 14 at 11:11











  • @TiagoCardoso updated :)

    – Blowsie
    Feb 14 at 11:37













  • Much better! Now I can die in peace, lol :D

    – Tiago Cardoso
    Feb 14 at 13:18











  • This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

    – Venture2099
    Feb 15 at 6:44
















4















Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.





Our team is fairly new to them and trying to figure out how to best apply them?



Here' the problem, per sprint;




  • A developer who is dealing with small tickets and requests might complete;



250 x XXS (1) = 250





  • The same developer who is working on a large feature might complete;



1 x XL (20) = 20




How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.





Our sizing chart (Fibonacci-ish)



| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |
|------|------|------|------|------|------|------|------|------|
| 1 | 2 | 3 | 5 | 8 | 13 | 20 | 30 | 50 |




Related:




  • Why use both story points and hours?

  • Story Points to Ideal Days

  • Forecasting Story Points in Agile

  • Alternatives to estimating in hours/story points










share|improve this question




















  • 1





    Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

    – nvoigt
    Feb 14 at 11:07











  • Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

    – Tiago Cardoso
    Feb 14 at 11:11











  • @TiagoCardoso updated :)

    – Blowsie
    Feb 14 at 11:37













  • Much better! Now I can die in peace, lol :D

    – Tiago Cardoso
    Feb 14 at 13:18











  • This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

    – Venture2099
    Feb 15 at 6:44














4












4








4








Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.





Our team is fairly new to them and trying to figure out how to best apply them?



Here' the problem, per sprint;




  • A developer who is dealing with small tickets and requests might complete;



250 x XXS (1) = 250





  • The same developer who is working on a large feature might complete;



1 x XL (20) = 20




How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.





Our sizing chart (Fibonacci-ish)



| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |
|------|------|------|------|------|------|------|------|------|
| 1 | 2 | 3 | 5 | 8 | 13 | 20 | 30 | 50 |




Related:




  • Why use both story points and hours?

  • Story Points to Ideal Days

  • Forecasting Story Points in Agile

  • Alternatives to estimating in hours/story points










share|improve this question
















Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.





Our team is fairly new to them and trying to figure out how to best apply them?



Here' the problem, per sprint;




  • A developer who is dealing with small tickets and requests might complete;



250 x XXS (1) = 250





  • The same developer who is working on a large feature might complete;



1 x XL (20) = 20




How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.





Our sizing chart (Fibonacci-ish)



| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |
|------|------|------|------|------|------|------|------|------|
| 1 | 2 | 3 | 5 | 8 | 13 | 20 | 30 | 50 |




Related:




  • Why use both story points and hours?

  • Story Points to Ideal Days

  • Forecasting Story Points in Agile

  • Alternatives to estimating in hours/story points







agile estimation sprint story-points sprint-planning






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 14 at 11:37







Blowsie

















asked Feb 14 at 10:23









BlowsieBlowsie

1265




1265








  • 1





    Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

    – nvoigt
    Feb 14 at 11:07











  • Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

    – Tiago Cardoso
    Feb 14 at 11:11











  • @TiagoCardoso updated :)

    – Blowsie
    Feb 14 at 11:37













  • Much better! Now I can die in peace, lol :D

    – Tiago Cardoso
    Feb 14 at 13:18











  • This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

    – Venture2099
    Feb 15 at 6:44














  • 1





    Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

    – nvoigt
    Feb 14 at 11:07











  • Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

    – Tiago Cardoso
    Feb 14 at 11:11











  • @TiagoCardoso updated :)

    – Blowsie
    Feb 14 at 11:37













  • Much better! Now I can die in peace, lol :D

    – Tiago Cardoso
    Feb 14 at 13:18











  • This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

    – Venture2099
    Feb 15 at 6:44








1




1





Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

– nvoigt
Feb 14 at 11:07





Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?

– nvoigt
Feb 14 at 11:07













Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

– Tiago Cardoso
Feb 14 at 11:11





Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)

– Tiago Cardoso
Feb 14 at 11:11













@TiagoCardoso updated :)

– Blowsie
Feb 14 at 11:37







@TiagoCardoso updated :)

– Blowsie
Feb 14 at 11:37















Much better! Now I can die in peace, lol :D

– Tiago Cardoso
Feb 14 at 13:18





Much better! Now I can die in peace, lol :D

– Tiago Cardoso
Feb 14 at 13:18













This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

– Venture2099
Feb 15 at 6:44





This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that.

– Venture2099
Feb 15 at 6:44










4 Answers
4






active

oldest

votes


















9














The official answer to the problem is:



There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.





However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?



Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.



With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.



With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.



Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.






share|improve this answer
























  • Also: is that big feature really one unit? Might it be better broken into several digestible parts?

    – mattdm
    Feb 14 at 13:44



















1














Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.






share|improve this answer































    1














    The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.



    This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).



    In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.






    share|improve this answer































      -3














      Ok, I will give you a better sizing chart.
      I think the problem is that you set up the wrong system.



      Before anything, you have to:




      • educate your team to give technical estimation and

      • take an average for a user story.


      Better sizing chart



      USER STORY SIZE  TIME ESTIMATE
      0 (-)
      1/2 (<1/2 h)
      1 (1/2 - 1 h)
      3 (1 - 2 h)
      5 (2 - 4 h)
      8 (4 - 8 h)
      13 (8 - 16 h)
      20 (16 - 24 h)
      40 (24 - 40 h)
      100 (40 - 80 h)


      Note: team estimate is average of all estimate






      share|improve this answer





















      • 6





        A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

        – Daniel
        Feb 14 at 14:36











      • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

        – MrScrumMaster
        Feb 14 at 15:26








      • 2





        So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

        – Cort Ammon
        Feb 14 at 17:20






      • 2





        If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

        – Daniel
        Feb 14 at 19:24






      • 1





        This is nonsense and your account must be a parody with that name.

        – Venture2099
        Feb 14 at 22:39












      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "208"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25823%2fstory-points-flaw%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      9














      The official answer to the problem is:



      There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.





      However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?



      Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.



      With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.



      With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.



      Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.






      share|improve this answer
























      • Also: is that big feature really one unit? Might it be better broken into several digestible parts?

        – mattdm
        Feb 14 at 13:44
















      9














      The official answer to the problem is:



      There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.





      However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?



      Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.



      With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.



      With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.



      Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.






      share|improve this answer
























      • Also: is that big feature really one unit? Might it be better broken into several digestible parts?

        – mattdm
        Feb 14 at 13:44














      9












      9








      9







      The official answer to the problem is:



      There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.





      However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?



      Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.



      With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.



      With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.



      Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.






      share|improve this answer













      The official answer to the problem is:



      There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.





      However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?



      Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.



      With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.



      With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.



      Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Feb 14 at 11:27









      nvoigtnvoigt

      3,902918




      3,902918













      • Also: is that big feature really one unit? Might it be better broken into several digestible parts?

        – mattdm
        Feb 14 at 13:44



















      • Also: is that big feature really one unit? Might it be better broken into several digestible parts?

        – mattdm
        Feb 14 at 13:44

















      Also: is that big feature really one unit? Might it be better broken into several digestible parts?

      – mattdm
      Feb 14 at 13:44





      Also: is that big feature really one unit? Might it be better broken into several digestible parts?

      – mattdm
      Feb 14 at 13:44











      1














      Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.






      share|improve this answer




























        1














        Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.






        share|improve this answer


























          1












          1








          1







          Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.






          share|improve this answer













          Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 15 at 8:10









          Denis P.Denis P.

          111




          111























              1














              The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.



              This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).



              In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.






              share|improve this answer




























                1














                The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.



                This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).



                In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.






                share|improve this answer


























                  1












                  1








                  1







                  The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.



                  This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).



                  In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.






                  share|improve this answer













                  The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.



                  This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).



                  In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 15 at 8:26









                  Bart van Ingen SchenauBart van Ingen Schenau

                  1,14269




                  1,14269























                      -3














                      Ok, I will give you a better sizing chart.
                      I think the problem is that you set up the wrong system.



                      Before anything, you have to:




                      • educate your team to give technical estimation and

                      • take an average for a user story.


                      Better sizing chart



                      USER STORY SIZE  TIME ESTIMATE
                      0 (-)
                      1/2 (<1/2 h)
                      1 (1/2 - 1 h)
                      3 (1 - 2 h)
                      5 (2 - 4 h)
                      8 (4 - 8 h)
                      13 (8 - 16 h)
                      20 (16 - 24 h)
                      40 (24 - 40 h)
                      100 (40 - 80 h)


                      Note: team estimate is average of all estimate






                      share|improve this answer





















                      • 6





                        A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                        – Daniel
                        Feb 14 at 14:36











                      • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                        – MrScrumMaster
                        Feb 14 at 15:26








                      • 2





                        So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                        – Cort Ammon
                        Feb 14 at 17:20






                      • 2





                        If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                        – Daniel
                        Feb 14 at 19:24






                      • 1





                        This is nonsense and your account must be a parody with that name.

                        – Venture2099
                        Feb 14 at 22:39
















                      -3














                      Ok, I will give you a better sizing chart.
                      I think the problem is that you set up the wrong system.



                      Before anything, you have to:




                      • educate your team to give technical estimation and

                      • take an average for a user story.


                      Better sizing chart



                      USER STORY SIZE  TIME ESTIMATE
                      0 (-)
                      1/2 (<1/2 h)
                      1 (1/2 - 1 h)
                      3 (1 - 2 h)
                      5 (2 - 4 h)
                      8 (4 - 8 h)
                      13 (8 - 16 h)
                      20 (16 - 24 h)
                      40 (24 - 40 h)
                      100 (40 - 80 h)


                      Note: team estimate is average of all estimate






                      share|improve this answer





















                      • 6





                        A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                        – Daniel
                        Feb 14 at 14:36











                      • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                        – MrScrumMaster
                        Feb 14 at 15:26








                      • 2





                        So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                        – Cort Ammon
                        Feb 14 at 17:20






                      • 2





                        If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                        – Daniel
                        Feb 14 at 19:24






                      • 1





                        This is nonsense and your account must be a parody with that name.

                        – Venture2099
                        Feb 14 at 22:39














                      -3












                      -3








                      -3







                      Ok, I will give you a better sizing chart.
                      I think the problem is that you set up the wrong system.



                      Before anything, you have to:




                      • educate your team to give technical estimation and

                      • take an average for a user story.


                      Better sizing chart



                      USER STORY SIZE  TIME ESTIMATE
                      0 (-)
                      1/2 (<1/2 h)
                      1 (1/2 - 1 h)
                      3 (1 - 2 h)
                      5 (2 - 4 h)
                      8 (4 - 8 h)
                      13 (8 - 16 h)
                      20 (16 - 24 h)
                      40 (24 - 40 h)
                      100 (40 - 80 h)


                      Note: team estimate is average of all estimate






                      share|improve this answer















                      Ok, I will give you a better sizing chart.
                      I think the problem is that you set up the wrong system.



                      Before anything, you have to:




                      • educate your team to give technical estimation and

                      • take an average for a user story.


                      Better sizing chart



                      USER STORY SIZE  TIME ESTIMATE
                      0 (-)
                      1/2 (<1/2 h)
                      1 (1/2 - 1 h)
                      3 (1 - 2 h)
                      5 (2 - 4 h)
                      8 (4 - 8 h)
                      13 (8 - 16 h)
                      20 (16 - 24 h)
                      40 (24 - 40 h)
                      100 (40 - 80 h)


                      Note: team estimate is average of all estimate







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Feb 14 at 13:18









                      Bart van Ingen Schenau

                      1,14269




                      1,14269










                      answered Feb 14 at 11:12









                      MrScrumMasterMrScrumMaster

                      984




                      984








                      • 6





                        A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                        – Daniel
                        Feb 14 at 14:36











                      • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                        – MrScrumMaster
                        Feb 14 at 15:26








                      • 2





                        So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                        – Cort Ammon
                        Feb 14 at 17:20






                      • 2





                        If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                        – Daniel
                        Feb 14 at 19:24






                      • 1





                        This is nonsense and your account must be a parody with that name.

                        – Venture2099
                        Feb 14 at 22:39














                      • 6





                        A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                        – Daniel
                        Feb 14 at 14:36











                      • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                        – MrScrumMaster
                        Feb 14 at 15:26








                      • 2





                        So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                        – Cort Ammon
                        Feb 14 at 17:20






                      • 2





                        If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                        – Daniel
                        Feb 14 at 19:24






                      • 1





                        This is nonsense and your account must be a parody with that name.

                        – Venture2099
                        Feb 14 at 22:39








                      6




                      6





                      A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                      – Daniel
                      Feb 14 at 14:36





                      A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.

                      – Daniel
                      Feb 14 at 14:36













                      It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                      – MrScrumMaster
                      Feb 14 at 15:26







                      It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart.

                      – MrScrumMaster
                      Feb 14 at 15:26






                      2




                      2





                      So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                      – Cort Ammon
                      Feb 14 at 17:20





                      So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.

                      – Cort Ammon
                      Feb 14 at 17:20




                      2




                      2





                      If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                      – Daniel
                      Feb 14 at 19:24





                      If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.

                      – Daniel
                      Feb 14 at 19:24




                      1




                      1





                      This is nonsense and your account must be a parody with that name.

                      – Venture2099
                      Feb 14 at 22:39





                      This is nonsense and your account must be a parody with that name.

                      – Venture2099
                      Feb 14 at 22:39


















                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Project Management Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f25823%2fstory-points-flaw%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Human spaceflight

                      Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                      張江高科駅