Scrum神话:没有完成所有的Sprint Backlog项目是失败的

我遇到的一个Scrum神话是，在一个Sprint中没有完成所有的Sprint Backlog项目被视为失败。我曾见过一些组织在Sprint Backlog完成百分比的基础上实施绩效指标。最近我与一名开发人员的谈话提醒我，这种误解的代价是多么高昂。

一个例子

一位疲惫的开发人员与他的团队一起努力工作，以解决一些非常棘手的问题。一个新的、不熟悉的技术正在被实现，在Sprint计划期间，开发团队乐观地认为它可以很容易地引入到产品中。尽管付出了勇敢的努力，开发团队还是完成了他们预测的一半。

“这个Sprint是一个史诗般的失败，我们几乎没有完成50%的Sprint Backlog，”开发人员说。当我问团队是否实现了Sprint目标时，他回答说:“嗯，我们实现了新技术，并将其部署到测试环境中，但我们并没有像我们想象的那样完成很多工作。”

产品负责人已经意识到开发团队在使用新技术时遇到的问题。他们与团队一起确定哪些Sprint Backlog项目是最值得完成的。在Sprint的过程中，他们就新技术的第一个可接受的实施方案进行了谈判。

尽管有这样健康和预期的对话，开发团队仍然有一种隐现的感觉，即开发团队已经失败了。值得注意的是，在这个例子中，失败的感觉来自Scrum团队本身，而不是来自外部影响者(利益相关者或管理层)。

Sprint Backlog的出现

期望开发团队在Sprint开始时就有一个完美的计划是与经验主义直接冲突的。在Scrum中，我们以每天都在进行计划和重新计划的经验为指导(参见Stephanie Ockerman关于Scrum计划的文章)//www.aspasp2011.com/resources/blog/scrum-myths-there-no-planning-scrum）.

在Sprint计划期间，开发团队将根据产品负责人对Sprint的期望来预测和选择工作。天气预报是根据当天的“天气”预报的。该计划被称为Sprint Backlog，当发现新信息时，它以与产品Backlog相同的方式出现。Sprint的更高级别目标，称为Sprint目标，是开发团队和产品负责人的范围谈判点。当Sprint目标受到不可预见工作的威胁时，开发团队向产品负责人提出问题，然后他们一起寻找解决方案。

本例中的开发团队对新技术的实现非常乐观和积极。然而，他们最初的计划并没有像他们预期的那样发展。他们在Sprint期间与产品负责人进行谈判，并保持Sprint目标的完整性。Sprint结束时产生的增量包括新技术的“已完成”实现，尽管它不包含最初预测的所有内容。

在这个例子中，重要的是，失败的感觉来自开发团队，这可能比来自外部影响者更容易补救。为什么会有失败的感觉?陷入困境的Scrum团队可以将此作为Sprint回顾的讨论主题，在Sprint回顾中，Scrum团队会面并讨论可以在下一个Sprint中进行的改进。

让我们想象一下，涉众或管理层对团队没有百分之百完成Sprint Backlog项目表示失望。在Scrum中经常使用的是一个称为速度的度量，这是一个开发团队在一个Sprint中完成多少工作的度量。

考虑以下几点:

• 如果这些外部影响者使用速度等指标作为绩效指标呢?
• 如果外部期望开发团队保持特定的速度或100%完成每个Sprint Backlog，会怎样?
• 士气会受到怎样的影响?
• 这将如何影响开发团队在透明方面的舒适度?

通常情况下，这些问题的答案会带来极其消极的后果。你有什么经历?

结论

Sprint中的成功并不是由是否完成了所有预测的Sprint Backlog项目来定义的。相反，成功是由产生的增量以及Scrum团队如何根据增量的反馈进行检查和调整来定义的。在像软件开发这样严重依赖于开发团队的知识和技能的领域中，找到“完成”的路径通常是在工作执行时实时发生的。允许Sprint Backlog出现，并利用Scrum框架根据经验来指导您。