Scrum 时间估算 - 团队规模
Scrum Time Estimation - Team Size
我们有一个由大约四名开发人员组成的团队，他们使用 Scrum 进行为期两周的冲刺。我们使用 YouTrack 并在 Sprint Planning 中执行时间估算时，我们很快完成了两周的工作。
问题是，例如，开发人员 John 会选择积压工作中的第一项，并说大约需要 1 天时间。开发人员 Brian 将接受下一个项目并说大约需要 1 天。当然，如果每个开发人员都处理每件作品，那实际上只有一天的工作量，但 YouTrack 会将其加起来为 2 天。
当整个团队不必同时处理同一项目时，我们如何适当地估计时间？我们是否在某处违反了 Scrum 规则？
如果我们做对了，而且我们只需要两周多的时间，我们如何确保我们没有给自己太多的工作？
据我所知和理解，您不会在 Scrum 中估算 努力。您估计 用户故事相互之间以及所包含功能的复杂性。
在此之后，您估计 故事点 ，而不是人工日。 燃尽图 显示了您团队的进度。随着时间的推移，你会得到相当准确的 团队速度 ，它基本上告诉你你的团队在每个 sprint.
中完成了多少个故事点
使用这个团队速度作为基础来决定是否为任何给定的冲刺提交另一个用户故事，或者它是否可能太多了。
它不应该只是复杂性，而应该包括复杂性、努力、风险和温和的常识。
我认为您一开始就以错误的方式进行估算，这与 Scrum、看板或 XP 无关。您正在以每个人为基础进行估算，而实际上应该以每个故事为基础进行估算。从整体上考虑功能，然后估计故事而不是单个成员为此付出的努力。
人工估算days/hours一直受到批评，因为它不涉及技能集测量。比如说，一个复杂度为 5 的功能可以由高级工程师在 1 天内完成，但新加入者或经验不足的成员需要 2 天。因此，您不能只考虑复杂性来衡量故事规模和冲刺承诺。
许多人仅使用复杂性来估算 Stories，然后根据小时数进行子任务，这也有缺点，因为在实际估算中需要重复工作。最重要的是，请始终记住，估算永远是估算，规划扑克只能帮助您找到它，但它不是最终的估算技术。
在这里加上我的五分钱，积压项目的复杂性 不是由个别团队成员判断的。
首先，待办事项很可能涉及不止一个团队成员，并且可以分解为更小的任务，例如 'implement UI'、'run tests' 或 'change the database schema'。因此，John、Brian 和 Mary（一名测试工程师）都会参与其中。因此，您需要为 整个团队 估算 'Complexity, Effort, Risk and a gentle touch of common sense'，而不仅仅是 John 或 Brian。
此外，作为资深人士的 John 可能会说它的复杂度为 2，而 Brian（初级）可能会说它的复杂度为 5，而 Mary 会注意到由于数据库模式更改而导致的大量回归并给它 8 . 最后，在 Scrum 中，整个团队对 sprint 的承诺。因此，作为 Scrum Master，您需要帮助 John、Brian 和 Mary 达成一致，这就是规划扑克等工具的用武之地。
我们有一个由大约四名开发人员组成的团队，他们使用 Scrum 进行为期两周的冲刺。我们使用 YouTrack 并在 Sprint Planning 中执行时间估算时，我们很快完成了两周的工作。
问题是，例如，开发人员 John 会选择积压工作中的第一项，并说大约需要 1 天时间。开发人员 Brian 将接受下一个项目并说大约需要 1 天。当然，如果每个开发人员都处理每件作品，那实际上只有一天的工作量，但 YouTrack 会将其加起来为 2 天。
当整个团队不必同时处理同一项目时，我们如何适当地估计时间？我们是否在某处违反了 Scrum 规则？
如果我们做对了，而且我们只需要两周多的时间，我们如何确保我们没有给自己太多的工作？
据我所知和理解，您不会在 Scrum 中估算 努力。您估计 用户故事相互之间以及所包含功能的复杂性。
在此之后，您估计 故事点 ，而不是人工日。 燃尽图 显示了您团队的进度。随着时间的推移，你会得到相当准确的 团队速度 ，它基本上告诉你你的团队在每个 sprint.
中完成了多少个故事点使用这个团队速度作为基础来决定是否为任何给定的冲刺提交另一个用户故事，或者它是否可能太多了。
它不应该只是复杂性，而应该包括复杂性、努力、风险和温和的常识。
我认为您一开始就以错误的方式进行估算，这与 Scrum、看板或 XP 无关。您正在以每个人为基础进行估算，而实际上应该以每个故事为基础进行估算。从整体上考虑功能，然后估计故事而不是单个成员为此付出的努力。
人工估算days/hours一直受到批评，因为它不涉及技能集测量。比如说，一个复杂度为 5 的功能可以由高级工程师在 1 天内完成，但新加入者或经验不足的成员需要 2 天。因此，您不能只考虑复杂性来衡量故事规模和冲刺承诺。
许多人仅使用复杂性来估算 Stories，然后根据小时数进行子任务，这也有缺点，因为在实际估算中需要重复工作。最重要的是，请始终记住，估算永远是估算，规划扑克只能帮助您找到它，但它不是最终的估算技术。
在这里加上我的五分钱，积压项目的复杂性 不是由个别团队成员判断的。
首先，待办事项很可能涉及不止一个团队成员，并且可以分解为更小的任务，例如 'implement UI'、'run tests' 或 'change the database schema'。因此，John、Brian 和 Mary（一名测试工程师）都会参与其中。因此，您需要为 整个团队 估算 'Complexity, Effort, Risk and a gentle touch of common sense'，而不仅仅是 John 或 Brian。
此外，作为资深人士的 John 可能会说它的复杂度为 2，而 Brian（初级）可能会说它的复杂度为 5，而 Mary 会注意到由于数据库模式更改而导致的大量回归并给它 8 . 最后，在 Scrum 中，整个团队对 sprint 的承诺。因此，作为 Scrum Master，您需要帮助 John、Brian 和 Mary 达成一致，这就是规划扑克等工具的用武之地。