如果有许多任务，如何管理故事点？

Question

我试图了解如何将故事点分配给子任务以及如何在Jira中管理故事点。

我有一个用户故事，估计有25分。 开发人员将把这个用户故事分解为许多任务。

他应该为每项任务分配一些故事点（25个）吗？总而言之，所有任务应该加起来多达25分？如果用户关闭了10个故事点的任务，那么Jira是否会知道10个故事点已经从25个主要用户故事中被烧掉了？

另外，如果在sprint结束时用户故事不完整（比如说只完成了20分），我是否会在下一个sprint中创建一个5分的新用户故事？

Answer 1

让我们暂时假装Jira不是问题。

首先，应该以小时为单位估算任务，而不是分数。

其次，故事只应在完成时计入烧毁状态。 （https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/）

第三，考虑从任务中获得的价值。在我们完成任务的团队中，我发现创建任务的工作是一个很好的验证器，可以很好地定义故事。标记任务对我的团队来说用处不大。

第四，当一个故事在sprint结束时没有完成时，它应该返回到产品经理重新确定优先级的积压。它可能不再是一个优先事项（特别是如果它花费的时间比预期的要长）。 https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint 来自scrum guide - “所有不完整

产品待办事项项目会重新估算并放回产品待办事项中。“

就个人而言，我不想重新估计，因为一些努力“失去了”。如果你没有重新估计，那么你的速度会随着时间的推移而平衡，即使每个单独的冲刺速度都会反弹。

在某些情况下，当故事往往很大时，估计花费超过4或5天时，您很容易在短跑中失去进度。如果冲刺持续2周，则尤其如此。

我曾与之合作的团队已经放弃了支持小故事的任务。 （目前，我们使用的规则是，如果它> 13个故事点，它可能太大而且应该分开）。

所有这些都考虑到了，Jira应该相当顺利。

Answer 2

我发现子任务是与JIRA中的敏捷一起使用的最难的功能。它总是最终成为两种情况之一，提醒我为什么我从不尝试使用子任务开始：

1. 每个子任务实际上都是一个故事，最初的故事太过广泛。每当我处于这种情况时，原始故事就会超过1个冲刺，如果不是很多冲刺（导致开发人员匆忙，推卸，压力等）
2. 或者，子任务本身太详细，不值得将JIRA作为自己的问题;相反，您应该添加注释来描述原始问题/故事的进度或反思，并避免JIRA开销。

编辑：回应@DaveHillier

我不喜欢创建子任务，因为它更多是JIRA俯卧撑。我认为子任务的吸引力在于它使你对JIRA的使用看起来更有条理，但我认为使用JIRA的一个重要部分就是尽可能减少问题的数量，但仍然对团队有效。我无法证明这一点，为什么我认为在这个帖子中问题数量应该很低，除了说“与JIRA，少即是多”。

让我告诉你我做了什么，满足以下要求：

• 问题的透明进展（如果需要，可以通知其他用户）
• 让我自己组织自己的想法
• 仍然与问题保持一致，让某人看我的故事并快速了解我在哪里

我在主要故事的描述中列出了一个列表，使用JIRA标记如下：

Build the thing. Lots of words blah blah.

h3. Progress
* code it
* test it
* deploy it

然后使用JIRA标记，我可以使用每个项目符号旁边的(/)添加一些绿色复选标记，让任何“监听”的错误都能跟上我的进度。

Build the thing. Lots of words blah blah.

h3. Progress
* (/) code it
* (/) test it
* deploy it

Answer 3

  

他应该为每项任务分配一些故事点（25个）吗？总而言之，所有任务应该加起来多达25分？

不，故事的任务没有分配任何点，因为一个完成的任务不会为客户端/最终用户提供太多价值。所有组合的任务将为最终用户提供一些有用的代码。从本质上讲，故事在完成所有任务之前是不完整的。请记住：Working software is the primary measure of progress。

  

如果用户关闭10个故事点的任务，Jira是否会知道10个故事点已经从25个主要用户故事中消失了？

由于任务没有任何要点（如上所述），这已经过时了。

  

如果在sprint结束时用户故事不完整（比如说只完成了20分），我是否会在下一个sprint中创建一个5分的新用户故事？

如果一个故事在sprint结束时仍然不完整，那么你有两个选择，要么将整个故事移回产品待办事项，要么将不完整故事的任何部分打包并视为工作软件然后将故事分成两部分。工作部分将在当前冲刺中被认为是完整的，非工作部分将成为产品积压的一部分。这部分将被视为一个新故事，应该作为一个单独的故事来估计。您无法在工作部分和非工作部分之间拆分故事点。

Answer 4

子任务在使用Jira Agile时效果不佳。

在我目前的团队中，我们不使用它们。

我不同意sethcall，没有理由说我应该使用子任务。

我想追踪我现在不能轻易做到的事情：

• 完成已完成定义的每个要点的任务
• 通过验收测试的任务

有些插件支持验收测试，（例如Behave for JIRA）但是我没有它们的经验。

有人向use custom fields建议您对完成（和验收测试）的定义，但我并不热衷于这个想法，因为列表中有太多例外。 这里有an article建议使用检查表进行验收测试。 可能值得一试。