8

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

我有一个用户故事，我们估计为 25 分。开发人员将获取此用户故事并将其拆分为多个任务。

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

另外，如果在 sprint 结束时用户故事没有完成（比如只完成了 20 个点），我是否要在下一个 sprint 中创建一个 5 个点的新用户故事？

4

4 回答 4

7

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

首先，任务应该以小时而不是点来估计。

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

第三，考虑你从这些任务中获得了什么价值。在我们完成任务的团队中，我发现创建任务的工作可以很好地验证故事是否定义得足够好。标记任务对我的团队没有多大用处。

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

产品待办事项项目被重新估计并放回产品待办事项。”

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

在某些情况下，当故事往往很大时，当它们估计需要超过 4 或 5 天时，您很容易忘记一个 sprint 中的进度。如果 sprint 持续 2 周，则尤其如此。

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

考虑到所有这些，Jira 应该很好地符合要求。

于 2014-01-19T15:20:20.273 回答
6

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

  1. 每个子任务实际上都是一个故事，而最初的故事太宽泛了。每次我遇到这种情况时，原始故事都会超过 1 个 sprint，如果不是很多 sprint（导致开发人员匆忙、推卸、压力等）
  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
于 2014-01-19T03:43:33.070 回答
5

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

不，故事的任务不会被分配任何分数，因为完成的任务不会为客户/最终用户提供太多价值。所有任务结合起来将交付一段工作代码，这对最终用户来说很有价值。从本质上讲，一个故事在完成所有任务之前是不完整的。请记住：工作软件是衡量进度的主要标准。

如果用户关闭了一个 10 个故事点的任务，Jira 会从 25 个主用户故事中知道 10 个故事点已经被烧掉了吗？

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

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

如果一个故事在 sprint 结束时仍然不完整，那么您有两个选择，要么将整个故事移回产品 backlog，要么如果不完整故事的任何部分可以挽救并作为一个工作软件处理，然后拆分故事一分为二。在当前 sprint 中，工作部分将被视为完成，非工作部分将成为产品 backlog 的一部分。这部分将被视为一个新的故事，它应该被估计为一个单独的故事。您不能在工作部分和非工作部分之间拆分故事点。

于 2014-01-20T11:32:03.713 回答
1

Sub tasks don't work well in with Jira Agile.

In my current team we don't use them.

I disagree with sethcall, that there are no reasons that I should be using sub tasks.

I'd like to track that I can't easily at the moment:

  • tasks for completing each point of a definition of done
  • tasks to make acceptance tests pass

There are plugins that support acceptance testing, (e.g. Behave for JIRA) however I have no experience of them.

Some have suggested to use custom fields for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list. Here is an article that suggests using checklists for acceptance tests. Might be worth a try.

于 2014-01-19T12:29:48.900 回答