我是一个相对较新的开发团队的成员Scrum
,假设在sprint结束时,一些大的故事是由PO决定in progress
还是不是accepted
。
首先,这些用户故事会发生什么?您是否只是将它们带入下一个冲刺?
如果是这样,是否应该重新估计它们?在我看来,这些用户故事上剩下的工作可能很少或很多?如果没有,为什么不呢?
编辑:在我的特定情况下,故事没有完成是因为存在几天的障碍,而不是因为用户故事被低估了。对于可能对您有用的人,我们正在使用VersionOne
我是一个相对较新的开发团队的成员Scrum
,假设在sprint结束时,一些大的故事是由PO决定in progress
还是不是accepted
。
首先,这些用户故事会发生什么?您是否只是将它们带入下一个冲刺?
如果是这样,是否应该重新估计它们?在我看来,这些用户故事上剩下的工作可能很少或很多?如果没有,为什么不呢?
编辑:在我的特定情况下,故事没有完成是因为存在几天的障碍,而不是因为用户故事被低估了。对于可能对您有用的人,我们正在使用VersionOne
Answers:
首先,这些用户故事会发生什么?您是否只是将它们带入下一个冲刺?
这取决于。如果没有其他故事具有更高的优先级,那么是的,它们将移至下一个冲刺。如果其他故事的优先级更高,那么如果sprint中没有足够的空间容纳它们,则可以将它们移回产品积压。所有这些都会在冲刺计划中进行,具体取决于产品负责人为每个故事分配的优先级。由于诸如Scrum之类的敏捷方法的目的之一就是在减少时间的同时最大化交付的价值,所以这一切都取决于完成这些故事所增加的价值。
无论发生什么情况,您都仍需要在冲刺结束时努力开发可能可发货的产品。这可能意味着要回滚以确保冲印结束产品通过所有测试,并且用户可以完全使用完整的功能,而不会出现任何重大问题。
如果是这样,是否应该重新估计它们?在我看来,这些用户故事上剩下的工作可能很少或很多?如果没有,为什么不呢?
我不会重新估计,因为在Scrum中,当您接受一个故事,开始工作并且没有部分完成的概念时,您会对其进行估计。一个故事要么是100%完成,经过测试并被接受(完成),要么没有完成。如果没有部分完成的概念,则无法确定故事中还有多少工作要做。似乎我也不孤单。您估算了您认为可以完成的工作,因此请保留此数据点,并在此处讨论为什么在冲刺事后评估中没有对估算值进行评估,并尽力避免在以后的冲刺中犯该错误。
通常,由选出的Scrum主管来决定超出冲刺的任务的处理方式,显然是在咨询了团队的其他成员和项目发起人/产品所有者之后。在冲刺结束时,是时候回顾一下优先级了。可能有问题的故事比新故事或现有故事的优先级低,并且将其作为“进行中”或您的跟踪器使用的任何标签放回跟踪器上,表明该故事将在另一点进行跟进及时。或者,故事可以被完全剥夺。您没有提到您正在使用什么跟踪器,但是我见过的大多数跟踪器都允许您将故事设置为“脱轨”(如果它不再属于项目的一部分)。
其次,由于您的团队是Scrum的新手,所以这都是学习过程的一部分。您现在已经意识到有些故事太大了,因此您的团队将需要更多时间来分解这些故事。确保发生这种情况通常是Scrum管理员的责任。Scrum主管还需要向项目发起人/产品所有者咨询不完整的故事,以尝试进一步分解或最终决定将其完全删除的最终决定权。
在我的团队中,每2周(冲刺)选举一次新的Scrum主管,因此每个人都可以轻松地管理任务,组织Scrum会议并确保每个人都提交进度报告。我希望您自己的团队就是这种情况,这当然是一次很好的经历。