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

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 来自sch 指南 - "全部不完整

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

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

在某些情况下,当故事往往很大时,如果估计故事花费的时间超过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标记,我可以添加一些绿色的复选标记,因为我(/)在每个项目符号点旁边完成,让任何"听众"的bug都能跟上我的进度.

Build the thing. Lots of words blah blah.

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

Answer 3

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

不,故事的任务没有分配任何点,因为一个完成的任务不会为客户端/最终用户提供太多价值.所有组合的任务将为最终用户提供一些有用的代码.从本质上讲,故事在完成所有任务之前是不完整的.请记住:工作软件是衡量进展的主要指标.

如果用户关闭了10个故事点的任务,那么Jira是否会知道10个故事点已经从25个主要用户故事中被烧掉了？

由于任务没有任何要点(如上所述),这已经过时了.

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

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