估计不完整的故事该怎么办?


11

我是一个相对较新的开发团队的成员Scrum,假设在sprint结束时,一些大的故事是由PO决定in progress还是不是accepted

首先,这些用户故事会发生什么?您是否只是将它们带入下一个冲刺?

如果是这样,是否应该重新估计它们?在我看来,这些用户故事上剩下的工作可能很少或很多?如果没有,为什么不呢?

编辑:在我的特定情况下,故事没有完成是因为存在几天的障碍,而不是因为用户故事被低估了。对于可能对您有用的人,我们正在使用VersionOne


我用XP过程中工作,并且一直想知道什么是应对这种情况的最好办法
chrisbunney

1
无法将障碍识别为可能的风险并无法确定风险暴露RE(影响*概率)表明估算存在问题。具有高RE的用户故事需要有更大的成本和时间缓冲区来应对这些风险,以解决这些风险。
Thomas Owens

将其加倍并添加32,就像C => F
Paul

Answers:


13

首先,这些用户故事会发生什么?您是否只是将它们带入下一个冲刺?

这取决于。如果没有其他故事具有更高的优先级,那么是的,它们将移至下一个冲刺。如果其他故事的优先级更高,那么如果sprint中没有足够的空间容纳它们,则可以将它们移回产品积压。所有这些都会在冲刺计划中进行,具体取决于产品负责人为每个故事分配的优先级。由于诸如Scrum之类的敏捷方法的目的之一就是在减少时间的同时最大化交付的价值,所以这一切都取决于完成这些故事所增加的价值。

无论发生什么情况,您都仍需要在冲刺结束时努力开发可能可发货的产品。这可能意味着要回滚以确保冲印结束产品通过所有测试,并且用户可以完全使用完整的功能,而不会出现任何重大问题。

如果是这样,是否应该重新估计它们?在我看来,这些用户故事上剩下的工作可能很少或很多?如果没有,为什么不呢?

我不会重新估计,因为在Scrum中,当您接受一个故事,开始工作并且没有部分完成的概念时,您会对其进行估计。一个故事要么是100%完成,经过测试并被接受(完成),要么没有完成。如果没有部分完成的概念,则无法确定故事中还有多少工作要做。似乎我也不孤单。您估算了您认为可以完成的工作,因此请保留此数据点,并在此处讨论为什么在冲刺事后评估中没有对估算值进行评估,并尽力避免在以后的冲刺中犯该错误。


1
我们只经历过一次,这与估计错误无关,我们有种障碍导致工作得以完成,但未经测试。
eatablecode 2012年

@ user1016253这意味着您的估计有问题。估算应包括风险暴露(影响*概率=暴露,其中暴露会影响成本,时间和质量)。因为发生了一个障碍,但估计没有考虑到它(或没有考虑到足够多的东西),所以某些东西被忽略或错误评估(影响或可能性太低,这意味着暴露是太低,意味着没有足够的资源分配来在问题发生时识别和纠正问题。
Thomas Owens

@ user1016253如果您在估计和查看风险和潜在障碍时遇到困难,也许一个好主意是将故事分解为多个故事,每个故事都放入待办事项中,或者分解为子故事,供开发团队使用以了解需要完成的工作。通常,在较小的工作单元上估计和执行风险分析通常会更容易。
Thomas Owens

1
@Thomas Owens:这似乎不是管理我风险的有用方法。特别是,不会造成灾难性影响的低概率事件就是低风险,因此,即使是一个管理良好的项目,有时也会有些偏离计划。如果您从不冒险,那么您将无能为力。当然,估算跟踪确实需要避免接受这样的借口,或者您得出的估算仅与导致最近抵押贷款崩溃的投资一样有效,并且出于同样的原因
David Thornley,2012年

@DavidThornley根本不是管理风险的方法,而是风险管理计划的起点,其中还包括检测和缓解策略。这是一种用于确保您的计划中有足够的金钱和时间来应对风险的技术。本文由软件评估中的Steve McConnell和Karl Wiegers 提出。重要的是要意识到它不是每个任务的缓冲区,但是项目(或迭代)缓冲区应该会带来各种风险。
Thomas Owens

1

通常,由选出的Scrum主管来决定超出冲刺的任务的处理方式,显然是在咨询了团队的其他成员和项目发起人/产品所有者之后。在冲刺结束时,是时候回顾一下优先级了。可能有问题的故事比新故事或现有故事的优先级低,并且将其作为“进行中”或您的跟踪器使用的任何标签放回跟踪器上,表明该故事将在另一点进行跟进及时。或者,故事可以被完全剥夺。您没有提到您正在使用什么跟踪器,但是我见过的大多数跟踪器都允许您将故事设置为“脱轨”(如果它不再属于项目的一部分)。

其次,由于您的团队是Scrum的新手,所以这都是学习过程的一部分。您现在已经意识到有些故事太大了,因此您的团队将需要更多时间来分解这些故事。确保发生这种情况通常是Scrum管理员的责任。Scrum主管还需要向项目发起人/产品所有者咨询不完整的故事,以尝试进一步分解或最终决定将其完全删除的最终决定权。

在我的团队中,每2周(冲刺)选举一次新的Scrum主管,因此每个人都可以轻松地管理任务,组织Scrum会议并确保每个人都提交进度报告。我希望您自己的团队就是这种情况,这当然是一次很好的经历。


4
Nitpick:决定如何处理不完整的故事是一个优先级问题。因此,我相信产品负责人应该决定这个,而不是Scrum主管。
sleske 2012年

@sleske-同意。我应该在回答中更清楚地说明这一点。最初我说过Scrum管理员会咨询团队,但是我应该包括项目发起人/所有者,我已经更正了。谢谢你的抬头。
荒凉星球

如果不完整的故事在冲刺结束时仍然不完整,那么您不能在那时真的将它们分解,因为这很可能会完全颠覆“完成”的定义-“那么,您是说故事的一部分已经完成?但这还没有经过代码审查!” 这就是为什么史诗般的单篇小说是可怕的,绝不应该被允许进入冲刺。
罗宾·格林

1
@RobinGreen我同意您对史诗的看法,但我不喜欢它们。回顾的价值(其中很多是我与之共事的人忽视了)是关键之一。我们最近开始使用JIRA的敏捷板,我经常向团队展示团队绩效的精简表。讨论不完整的故事是否发生以及何时发生,然后立即重新提交积压。在回顾中,我们看看故事为何不完整。缺乏资源?缺少知识?或两者的松散组合。
荒凉的星球
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.