2014年11月24日星期一01:00

分裂故事-您是什么意思?

撰写者

在关于Agile ALM工具Rally的LinkedIn讨论中,我看到了以下一系列片段。当您阅读它们时,请耐心等待,以获取我们讨论的背景信息…

原始问题

我有一个严重的案例:“我想回到JIRA 敏捷”。

我对Rally的最新挑战是在冲刺结束时找到处理未完成故事的最佳和最真实的方法。

故事:作为ScrumMaster,我希望将3个未完成的故事从Sprint 1平稳地移至Sprint 2,以便团队在下一个sprint中拥有这些故事,而不会影响Sprint 2或积压的速度,并且不会给ScrumMaster带来更多开销。

验收标准:

  • 总积压故事点保持真实
  • 先前冲刺的速度保持真实(准确反映了承诺)
  • 它不会在ScrumMaster或执行此操作的人上增加大量开销
  • 它不需要自定义应用程序即可执行此操作

期待您的反馈!

回复#1
对上面的内容稍作修改。我们拆分故事(实际上创建了一个父母和另一个孩子),然后Rally将自动拆分已完成和未完成的任务。然后,非常重要的一点是,将“未完成的故事点”设置为0。Rally将原始点分配给每个同级。这将产生比实际更大的速度的错觉。有人分配了积分,但我认为“完成或未完成”(没有尝试!) 

将未完成的故事标记为已完成,但未接受。然后,当“继续的同级”完成并被接受时,返回并接受未完成的同级。这样,功能%done就可以了。我怀疑父母没有计入故事总数,但我必须检查一下。

回复#2
这是困难的一个。 Rally的拆分解决方案在其他方面是个好主意,但始终需要权衡实现,以将故事从sprint过渡到sprint。在史诗下创建两个具有相同观点的故事,并且任何项目范围报告都将加倍。如果您将故事设为零分,则仍然需要弄乱状态,以确保不影响要素统计信息。直到集会创建一种方式,使故事在冲刺1中“具有历史性”,而现在在冲刺2中(与同一故事一样),您需要进行权衡。

我通常只是将故事向前推进,因为我主要关注已完成的工作,而不是关闭sprint后未接受的工作。我发现需要了解团队遗漏的内容仅对回顾有价值。不超过。我仅在Rally之外保存一份关于承诺积分与赚取积分的外部电子表格,以获取统计信息,以便团队可以查看他们是否持续超额/不足承诺。不是故事改编。

反应

我的第一个反应是,一个工具(任何工具)如何接管敏捷团队中的对话。在这里,该工具的功能正在驱动三位领导者在各自敏捷团队环境中的大部分思考。

他们似乎也非常担心“报告”。它们是否公平地代表了速度/点,观察者是否会通过检查趋势获得“正确”的印象?

这说明了为什么我一开始不喜欢“带头”工具。最后,我们没有关注有效的敏捷性原则和实践,而过分担心工具和数据报告。

我如何处理未完成的工作

我知道这可能有点严重,但是我将与您分享我喜欢如何处理未完成的工作。我这样做已经十多年了。不一定知道我从哪里开始,什么时候开始的,也不知道谁在这个方向上影响了我。我认为这是大多数基本的敏捷项目管理书中所建议的,但是我没有扎实的参考。

开始了:

  1. 如果用户故事尚未完成(按照团队的“完成”的定义),则他们对于当前冲刺中的任何故事点均不会获得任何信用
  2. 如果产品负责人认为故事是正确的,它将移至下一个冲刺(完成或删除)
  3. 在回顾中,团队讨论了如何更好地实现现实目标并完成工作
  4. 在Sprint Planning中,团队计划其余工作以清理或完成故事
  5. 当故事在下一个冲刺中完成时,团队将意识到所有故事要点

基本上,此模型加强了以下概念:

  • 团队因未完成的工作而未获得部分学分
  • 团队致力于冲刺中的工作,并交付(或更多)工作
  • 团队使他们的工作和动态透明
  • 团队为持续改进而努力

当我尝试影响每个团队遵循基本敏捷原则时。是的,我知道大多数敏捷工具都在与这个概念作斗争。他们通常希望从“会计”角度“分解”故事。

争论

我总是收到有关这种方法的争论。

首先是对团队速度的影响。显然,如果一个团队的平均速度为25,并且错过了8分的故事,那么他们的速度可能为17分,然后在随后的冲刺中为33分。每个人都可以清楚地看到这种“动荡”,并可能引起不舒服的谈话。它很丑。它使利益相关者注意。它使可预测性和预测变得困难。

究竟!

另一个论点是团队将士气低落。

为什么?他们显然对这个故事有些挣扎,需要重新评估他们的估计和工作计划。所以呢?新团队会发生这种情况,此事件将使他们的回顾产生健康的讨论和调整。

在我看来,这全都归结为算术。无法解决,因此我们有一个决定。我们是分开报道还是部分赞誉(隐藏该问题),还是我们会妥善处理它,继续前进,并努力在下一次变得更好?

边栏故事

我曾经指导过一个组织,该组织的每个团队都有大约25%的冲刺故事在每次冲刺结束时仍然不完整。事情发生得如此频繁,以至于他们为他们创造了一个术语-延续故事。

情况变得更糟。延续故事倾向于跨多个Sprint进行级联。实际上,在最终完成并视为“完成”之前,他们平均跨越了3-4个冲刺。

由于他们在每次冲刺结束时都会“拆分”工作,因此它们的速度看起来很不错。而且由于“延续故事”成为了常态,所以回顾性地讲,他们并没有太多地谈论它们。

但是,他们的客户引起了注意,并意识到每个Sprint都丢失了25%。不仅如此,而且未完成的工作会爬入随后的冲刺,并不断破坏团队正在交付的工作量。

关键在于-它被注意到了,但不是“好”。

包起来

我一直想讨论由于执行和交付动态而导致的故事拆分。我认为拉力赛论坛上的另一个讨论也是发起者。

不是说工具不好。但是事实是,它们鼓励我们专注于“算术”,而不是我们想要在敏捷团队中灌输和启发的行为。

在这种情况下,我不在乎速度的解释或对湍流的反应。它发生了。我希望团队关注的重点是(1)坚守完成的定义,(2)如果事情还没有完成,请确定发生了什么–探索根本原因,然后(3)为此做点什么提高他们计划和兑现未来承诺的能力。

无论您是否“拆分”您的故事,我都希望本文能使您停下来思考一下如何在Sprint中处理部分完成的工作。

保持敏捷,我的朋友们,
鲍勃

不要忘记在下面留下您的评论。

罗伯特·加伦

罗伯特·鲍勃·加伦 是RGCG L.L.C的总裁兼首席顾问。基于NC的Cary敏捷方法指导&培训顾问。他是一位经验丰富的敏捷教练,活跃于敏捷社区并定期撰写文章。&讲授与敏捷方法有关的所有主题。鲍勃写了这本书 Scrum产品所有权,重点放在团队交付中的角色和驱动价值上。鲍勃可以在 [email protected] 并通过他的LinkedIn进行联网 个人资料.

©BA Times.com 2020

麦格雷戈徽标白色网站