我对故事估计的理解是，应该像想象中的普通开发商那样估计故事的大小，这有点像法律上的“合理旁观者”概念。也就是说，如果您必须这样做，则不应该估计故事的大小。
举个例子：在我之前的工作中，我是一个团队的成员，而我是最自信的Ruby开发人员。我的队友通常会估计与Ruby有关的故事要比我估计的要大得多，并带有诸如“好吧，我不知道X在Ruby中如何工作，所以这需要我很多年。”
我反对这一观点的原因是，冲刺计划是团队能力发挥作用的地方。那是正确的说法，“由于大多数任务都是基于Ruby的，而且我们只有一名强大的Ruby开发人员，因此我们的Sprint容量将比平时低一些”。在估计期间将此因素考虑在内会使该方面加倍。
我会很乐意回答任何权威性的参考文献，但是简单的意见也将是很好的。
Answers:
故事点是相对估计。因此，两倍的积分意味着两倍的努力水平。相对估计较少受技能水平变化的影响。问题不在于您要花费1分要花费多少时间，而是2分需要2倍的潜在努力。如果您选择理想的日子而不是故事点，那么技能水平可能会更重要，因为您假设的是个人的生产率水平。
相对估计更为可靠。此外，故事点评估不应由个人来执行，而应由团队的集体努力来完成。对于不太复杂的故事，通常会很快达成协议。对于更具挑战性的故事，团队将获得大多数成员都同意的结果，因此暗含了团队的集体技能水平。
最后，故事评估是在团队中的任务尚未确定时进行的。这是不考虑个人技能水平的又一个论点。对于冲刺计划，您将利用团队的故事点能力，该数字将根据实际绩效数字进行演变，以便能够根据团队的整体技能水平进行自我调整。
总之，估计中不应考虑个人能力。但是，即使可以做到这一点，由于总体估计以及相对方法的鲁棒性，它并不重要。
规范的答案是，您不应更改每个开发人员的估算值。那将意味着您每个sprint所获得的积分要比同龄人高出很多，这很好，因为积分可以衡量团队的速度，而不是开发人员的速度。业务可以估计团队将产生多少以达到对交付的粗略期望，并且一切都很好。
但这在实践中会引起各种麻烦。如果那周放假怎么办？当复习时间到来时，您意识到您正在以200％的平均薪水和110％的平均薪水产生故事，会发生什么？当企业开始认为团队速度除以人员实际上是一个准确的近似值时，会发生什么？当企业意识到您所产生的错误比同行多（而忽略您所产生的功能更多）时，会发生什么？当人们有各种各样的叮咬时，什么构成“叮咬大小”的故事？
在我的职业生涯中发现的是，这并不重要。流程可以为您服务，反之亦然。如果您的组织需要评估开发人员是否过载，那么按开发人员的故事点是一个很好的解决方案。如果您的组织需要衡量团队的速度，那么与开发人员无关的故事点将提供更清晰的画面。但是它们总是近似的，并且总是会被滥用和误解。
最终，他们的制作过程，你需要适应由点您的环境。
TL; DR
我们应始终假定只有胜任的开发人员才能分配给特定故事。能力（或缺乏能力）不是侮辱。这只是对既不落后也不缺乏经验的开发人员技能的合理衡量。
这可能与特定公司的方法有关。我见过公司为特定的开发人员量身定制估算。我还看到一些公司实施了一个系统，其中三个随机选择的开发人员在几乎随机分配一个开发人员（而不是最初的三个开发人员中的一个）之前执行故事评估。
每个系统都可以工作，每个系统都可能发生故障。问题不在于哪个系统更好，而是公司能够/愿意解决哪些缺陷。
原则上，不应包括用于掌握语言/框架的学习时间。次要切线：尽管它们在理想世界中不应该存在，但应包括针对项目或故事特定障碍的学习时间。
这样做有很多理由，但是我相信这种方法通常是更好的选择，因为它符合估算工作量的意图。我认为这可能只是问题，而不是客观性。我不能肯定地说。
学习时间是个人的。对于需要开发特定技术的特定开发人员来说，这是一个范围。在评估用户故事的工作负载时，这无关紧要，因为用户故事仅在应用程序（及其使用的技术）范围内。
学习时间通常不会叠加。假设我们的新秀对C＃几乎一无所知，并且我们估计他在完成工作之前还需要三天的时间来弄清环境。就像我工作过的许多公司中的常见情况一样，我们现在正在开会时（预计会）估计多个用户案例。为了举例说明，假设我们要处理三个故事。
注意：
在其他情况下，学习时间确实会增加，例如，如果三个故事的主题完全不同，并且要求的技能也不同。
但是要确定是否存在这种情况，我们需要同时查看所有三个故事，这慢慢开始违反了拥有独立用户故事的原则。如果我们在不同的会议上讨论了这些估算，可能有不同的开发人员在场；我们将无法准确评估故事之间的重叠。
因为我们不能保证最终会完成哪些故事（客户可能会拒绝大笔的估计），以及谁将被分配给他们，所以试图说明要分配给特定故事的特定开发人员是徒劳的。最终只会使水变得浑浊。
取而代之的是，我们应该假设新手已经被提速（因此与他的同事是平等的开发者），以估计工作量。
这样的估计是开发人员不可知的，因此估计的正确性不会随最终分配给故事的开发人员而波动。
注意
必须承认某个特定的开发人员可能需要更多的时间来学习才能解决特定的故事，这仍然很重要。这仍然是一个非常相关的考虑。但是，这种考虑不应附加到故事中，而应将特定开发人员分配给该特定故事。
但是，从我开始时，这可能因公司而异。一些公司可能不会对学习时间感到困惑（例如，如果开发人员不可避免地不得不学习使用该技术）。其他人可能会严重依赖这些估算的准确性，因为它会影响向客户的结算。
最后，这是挑选毒药的问题。这些方法都不能保证比其他方法更准确。
这是一个复杂的主题，对此主题经常有争论。我对此不喜欢“规范”意见的概念：有各种有价值的意见。但是，应该有一些指导性价值观，原则和实践来指导这种方法。
以下是基于我自己与Scrum团队合作超过10年的观点。但这只是我的意见。
故事点作为一种预测方法故事点的初衷是找到一种快速的方法来估算工作量，目的是预测团队在一段时间内可以完成的工作。一些“专家”指出，积分仅用于预测长期范围（例如，在发布中），而不用于确定冲刺级别的容量。此外，概念是团队根据历史值应用“相对大小”（努力X与努力B相似，为3分）。这加快了估算过程，因此团队不必将未来的工作分解为详细的工作包，也不必花几个小时来处理所有任务。高绩效团队努力使所有技术工人成长为具有相似技能水平的非常称职的成员。（将在第4点中进一步探讨该概念）。一旦实现，个人技能水平实际上就不会成为规模调整的变量。但是：通常需要很长时间和共同的努力才能实现该目标。那么...到达那里之前我们要做什么？
任务时间确定冲刺容量：根据同一位“照明专家”的说法，他们将点用于长期预测，他们还建议使用任务时间来确定冲刺容量，而不是点。以我的观点，这很好，但是我会说，当我帮助教练团队达到“高性能”时，他们的升级技能平均可以在仅使用Story Points的情况下就可以准确地确定自己在冲刺中可以完成的任务。同样，这可能是我们努力追求的目标，但是新团队尚未为此做好准备。因此，您可能会在一个Sprint中找到一个故事，该故事有2分，需要12个工作小时的工作量，而另一个则有25小时的工作量。所以你会怎么做？我称之为“敏捷主义者”的某些人会说，故事的大小（以磅为单位）应该与持续时间无关。其他人则不同意。通读第3项的逻辑，然后看看您的想法。
因此，团队要着眼于一项工作，需要就这些要点达成共识，这些要点将成为“努力水平”的代名词。对？假设所有技能都是平等的，那么容易达成共识。但是，通常团队中有一个是Java专家的人，另一个不是Java方面的专家（也许她是C＃、. Net或Cobol的人，并且正在学习Java）。因此，鲍勃的任务X非常简单。对于简而言，这更加困难。
敏捷团队试图促进集体代码所有权以及不断增长/扩展的专业知识。因此，我们通常不会根据人们的专业知识为他们分配故事：我们更喜欢团队共同研究故事并一起学习。这与“放慢速度以加快速度”的概念相吻合：如果我们花时间向Jane讲授Java经验，虽然这可能一开始会使我们放慢脚步，但后来我们将有更多有能力的Java开发人员。实际上，如果我们只有一名Java专家，并且每个人都在各自的专业领域内工作，那么我们正在创造一种具有多个潜在“故障点”的情况。当90％的工作是Java，但Bob（我们的Java专家）生病或休假时，在sprint中会发生什么？通过扩展技能，我们消除了潜在的瓶颈并降低了风险。考虑到这一点：当团队查看故事时，他们在确定大小时应该考虑几个概念。您可以想到首字母缩写VUCK来记住这一点。
量：有些工作很简单，但是需要大量重复任务。（我有一个人必须复制并重新格式化50个以上的表，他说这是1点，因为它很简单。但是经过反思，团队意识到这很简单，但很耗时，并且有大量表要进行移动和优化。由于工作量大，我们不得不重新调整点数）
未知数：有时我们认为我们知道该怎么做，但我们也会识别一些未知数-这些代表风险。这意味着我们可能会遇到无法解决的问题，必须解决，重新设计或尝试其他解决方案。
复杂性：这一点很明显。一些解决方案在技术上很复杂。我们确切地知道该怎么做，但这需要技术专家。复杂性还意味着一些风险，不是吗？因此，即使我们所有人具有相同的技能，技术上的复杂性也意味着我们可能会遇到无法预料的挑战。因此，我们可以使这个故事更大。
知识：我们真的知道我们要解决什么吗？有时客户对他们想要的解决方案并不完全清楚，我们正在做一些试验。也许没有人实施过这种解决方案（以前从未使用过的新技术），所以我们不知道自己不知道什么。
我认为，这些考虑因素中的每一个实际上都是延长期限的代理。简单的故事，很多？这将需要更长的时间，否则我们需要分开谈谈。未知数？增加了风险，研究，实验，可能需要更长的时间，或者我们需要分开谈谈。复杂？增加了风险，需要修复错误，重新设计等，因此可能需要更长的时间。不知道我们是否具备必需的知识？我们还有其他风险，可能需要进行实验等，因此可能需要更长的时间...
看到这是怎么回事？因此，尽管故事要点的概念使我们不愿意在估算时考虑持续时间，但另一方面，拥有一个可以在4小时内完成的1点故事和另一个简单但需要花费1点时间的故事是不合逻辑的2周。
因此，如果Jane自愿承担Java的工作，而如果Bob这样做的话，那会使工作的时间是相同工作时间的2倍或3倍，那么您该怎么办？随着时间的流逝，我的团队决定根据工作水平（LOE）/ VUCK为工作人员确定故事大小。对于Guru团队的Bob，说“ 1”是没有意义的，而对于Jane来说，这并不容易，需要一周的时间才能完成，而且还需要Bob花费一些时间进行配对编码和代码审查。因此，我们提高了这些点以反映真实的LOE。下一次类似的故事出现时，简的8变成了以前的5。最终，每个人都同意这是简单的3。那时，我们知道我们正在成长。
TLDR
不，但可能不是您想的原因。
长版
许多其他答案都解释了“故事点”应该纯粹根据其他作品来计算。这是绝对正确的。随着故事点估计量的工作，而不是所需要的时间来完成它，然后它是没有意义给基于个人故事点。
例如（我的最爱之一），考虑您的任务“挖一个洞”。您可以根据要去除的土壤量或去除地球所需的时间来估算。我的朋友以每小时3米的速度挖矿整车，我有一个大型机械挖土机，因此我可以管理100个矿井！唯一的常数是地球的数量-因此，这就是我们用作估算单位的内容。
但是，降低开发人员估计用户故事的能力的第二个原因（在我看来更重要）是以下事实：几乎每个用户故事都可能由多个人处理。
您可能有一个架构师，一个开发人员，一个测试人员，或者另一个开发人员来执行UI。在您的用户故事被标记为“完成”（理想地部署并完成）之前，许多不同的人将对此进行处理。突然之间，基于相关开发人员进行估算的想法几乎没有意义，准确估算团队需要投入多少精力的唯一方法是测量团队的速度并估算团队要完成的工作。
团队中没有“我”，在敏捷计划中绝对没有我！