Scrum：如何处理超过一个冲刺的积压项目

我从SCRUM开始，我在理解一件事时遇到了问题。SCRUM如何处理耗时超过一个冲刺的积压项目？

此类项目称为Epic，必须分为较小的用户故事，该故事要短于单个冲刺，因此可以计划，而主题可以分为史诗和普通故事。史诗和主题具有主要特征-高度不确定性=无法正确估算（估算值通常很高，因此它们无法放入单个冲刺中）。

因此，最好从这样的故事开始，但是直到产品所有者将它们分解成较小的特定故事之前，您才能计划它们。这些故事仅用于记录一些较大的请求功能（Epic）或整个功能集（Theme）。打破这些故事将使功能变得特定。

它还遵循产品积压的Iceberg结构。

您没有此类物品。如果有的话，那么积压的项目还不够具体，还没有适当地分解成较小的项目。某些人称它们不是积压，而是fat积项目，在Scrum中，它们被视为反模式。

类比蛋糕的用户故事：作为吃蛋糕者，我想在下午吃蛋糕。我不能在一个下午吃整个蛋糕，所以需要切成薄片以适合我可以吃的量。

当Scrum首次被“发明”时，默认的sprint通常为4周。

据我所知，冲刺这么长的原因仅仅是因为当时人们很难想象您可以在短距离冲刺中完成任何事情。

随着团队对scrum更加自信，他们学习了如何更好地将积压项目划分为更易于管理的较小项目，而开发团队则在不过度进行前期设计而做得足够的情况下变得更好。

今天，我相信大多数团队会认为4周是很长的冲刺持续时间。我的印象是2周是很正常的。XP团队仅进行1周的迭代，并且每次迭代都完成完整的用户案例。

因此，您需要更好地将积压项目划分为较小的项目，以使每个最终产品的业务价值都有较小的增长。有可能，这已经被证明。（尽管我不排除可能存在非常困难的非常专业的领域）

我同意这几天的漫长冲刺是4周。您希望减少反馈回路，并希望在较短的迭代中更好地解决小工作量。这样一来，出错的地方就更少了，改变的地方更少了，一口气管理起来的复杂性也降低了。

拆分故事通常是人们的麻烦所在，但做得越多，您就会越受益。如果可以分阶段交付PO并仍然在sprint中交付价值，则与PO紧密合作以进行计算。

这是一个很棒的海报，可以帮助您分解故事，它来自agileforall.com网站，您可以在此处找到海报，在您完善积压项目时将其张贴起来非常有用：

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

在完善和计划时，使完成的定义可用也是很好的，这样，当您承诺在短时间内完成某件事时，可以牢记这一点。