Scrum时间估算 - 团队规模

Question

我们有一个由四名开发人员组成的团队，他们在Scrum工作了两周的冲刺。我们使用YouTrack，在Sprint Planning中执行时间估算时，我们会快速完成两周的工作。

问题是，例如，开发人员约翰将选择积压的第一项，并说它需要大约1天。开发人员Brian将采取下一个项目并说它将在1天左右。当然，如果每个开发人员都在每件作品上工作，那实际上只有一天工作，但是YouTrack会将其总计为2天。

当整个团队不必同时处理同一个项目时，我们如何恰当地估计时间？我们在某个地方违反了Scrum规则吗？

如果我们做得对，我们只需要两周时间，我们如何确定我们不会给自己太多的工作？

Answer 1

它不应该只是复杂性，而是包括复杂性，努力，风险和温和的常识。

我认为你开始以错误的方式进行估算，这与Scrum，看板或XP无关。您是按每个人估算的，应该基于每个故事实际完成。考虑整个功能，然后估计故事，而不是单个成员的努力。

按人日/小时估算一直受到批评，因为它不涉及技能组测量。比如，一个具有复杂性5的特征可以在一天内由高级工程师完成，但是对于新的木匠或经验较少的成员需要2天。因此，您不能仅考虑复杂性来衡量故事规模和冲刺承诺。

许多人仅使用复杂性来估计故事，然后根据小时来确定子任务，这也存在缺陷，这是由于实际估算中的重复工作。最重要的是，请记住，估计总是一个估计值，规划扑克只能帮助您找到它，但它不是最终的估算技术。

Answer 2

在这里添加我的五美分，积压项目的复杂性不会由个别团队成员判断。

首先，积压项目很可能涉及多个团队成员，并且可以分解为较小的任务，例如实施UI＆＃39;运行测试＆＃39;或者＆＃39;更改数据库架构＆＃39;。因此，John，Brian以及Mary（测试工程师）都会参与其中。因此，您需要估计复杂性，努力程度，风险和温和的常识。对于整个团队，不仅仅是John或Brian。

约翰，作为一名资深人士，可能会说它具有复杂性2，而布莱恩（一名大三学生）可能会说它是5而玛丽会因为数据库架构的变化而注意到很多回归并给它8。 Scrum结束了冲刺的整个团队的承诺。因此，作为Scrum Master，您需要协助John，Brian和Mary达成协议，并且在这里，计划扑克等工具会出现在舞台上。

Answer 3

据我所知和理解，你不估计Scrum中的努力。您估计用户故事相对于彼此和所包含功能的复杂性。

在此之后，您估算故事点，而不是人日。 燃尽图显示了团队的进度。随着时间的推移，您将获得非常准确的团队速度，它基本上可以告诉您团队使用每个sprint 完成了多少故事点。

使用此团队速度作为基础来决定是否为任何给定的sprint提交另一个用户故事，或者它是否可能过多。