Closed. This question is opinion-based。它当前不接受答案。












想要改善这个问题吗?更新问题,以便editing this post用事实和引用来回答。

3年前关闭。



Improve this question




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

我有一个用户故事,我们估计它有25分。
开发人员将获取此用户案例并将其分解为许多任务。

他是否应该为每个任务分配25个故事点?因此,所有任务总计应加25分?并且,如果用户关闭了10个故事点的任务,吉拉(Jira)会知道从25个主要故事的主要用户故事中燃烧了10个故事点吗?

另外,如果在sprint结束时用户故事还不完整(例如仅完成了20分),我是否在下一个sprint中创建5分的新用户故事?

最佳答案

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

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

其次,故事只应在完成后计入烧毁的记录中。 (https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/)

第三,考虑您从任务中获得什么值(value)。在完成任务的团队中,我发现创建任务的工作很好地验证了故事的定义是否正确。标记任务对我的团队没有多大用处。

第四,当故事在冲刺结束时未完成时,应重新提交待办事项列表,以使产品经理重新确定优先级。可能不再是优先考虑的事情(尤其是花费的时间比预期的要长得多)。
https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint
scrum guide-“所有不完整

产品待办事项的项目将被重新估算,并放回产品待办事项中。”

就我个人而言,我不喜欢重新估计,因为那样会浪费一些精力。如果您不重新估算,那么即使每个冲刺速度回落,您的速度也会随着时间的推移而平衡。

在某些情况下,当故事往往很大时,估计它们花费的时间超过4或5天,那么您很容易就无法在冲刺中跟踪进度。如果冲刺持续2周,则尤其如此。

我与之合作的团队已经放弃了任务,转而使用较小的故事。 (当前,我们使用的规则是,如果故事点数大于13,则可能太大,应该拆分)。

考虑到所有这些因素,Jira应该会表现得很好。

关于jira - 有许多任务时如何管理故事点?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/21212825/

10-12 19:15