我使用 Scrum 已经有一段时间了，但是对于所有团队成员工作速度不同的情况如何处理，我仍然没有清晰的认识。例如，给定一个抽象任务，员工 A 将在 5 天内完成，而员工 B 大约需要 10 甚至 15 天。我的团队由非常不同的（专业知识）人员组成，因此他们以不同的速度工作。
这些是主要的误解：
如何在理想的工作日衡量用户故事，因为它们在团队内部非常不同？（经常有争论，因为有些人在该领域有经验，有些人没有，所以他们需要花一些时间阅读文档并做一些小步骤）
如果我需要计算每个人的速度然后才能为每个人分配适量的工作，为什么还要计算团队速度？（计算每个人速度的另一个原因是，当一个高级家伙去度假和一个初级家伙去度假时存在很大差异）
Velocity 只是为了让团队可以粗略猜测下一个 sprint 可以投入的工作量。
故事点仅具有相对于另一个故事的意义，而不是绝对值，因为它们的唯一目的是在整个团队到现在为止已完成的故事与它必须在未来。
如果高级开发人员去度假，只需相应地调整下一个 sprint 的计划速度。不要把它作为引入复杂估算的借口，它们只会给你一种错误的安全感，让你陷入分形估算的泥潭，分散你的主要目标，即提供价值。
您不需要将故事点与工时联系起来。您不需要计算团队成员特定的估计值。您无需将故事预先分配给人们。
Scrum 没有个人绩效的概念。总是与团队有关。你总是会有不同程度的人表现出来，如果你试图为此做好计划，它会让你慢慢发疯。
我强烈的建议是忽略个人的表现，专注于团队的速度。
我的 2 美分：我所有的项目都包含 Scrums。处理这种情况的最好方法是让团队成员选择他们的故事并给他们打分。3分是可以快速完成的故事，可能是4小时或更短，8分是需要一个人在1个工作日（8小时）内完成的故事，13分（3天或更短）是故事将要求该人对实施，实施和测试进行一些研究
应该有领导团队开发人员了解其他团队成员的工作速度，并可以根据他们的能力将故事分配给其他成员。
如果您认为故事需要 3 天以上才能完成，那么应该将其进一步划分为所需时间更少的迷你故事。