我目前正在为 Scrum 团队开发一种生产力工具，并且想知道您在任何特定时间在产品积压中看到的平均故事数量是多少。
只是为了澄清这个数字不应包括已完成的故事或将来“可能”分成多个故事的故事。此外，我对人们“正在”做什么而不是他们“应该”做什么感兴趣。
不幸的是，我没有足够的时间去其他人的实验室，所以只有真正了解我们正常情况的经验。
我猜这个网站上有很多顾问可能会比我看到更多的团队会议室。
现在我知道这是一个“一根绳子有多长”类型的问题，有些人有两个，有些人有 2000 个，但我只是在找一根尺子。
我们公司的团队通常不到二十人。
问候，
克里斯
【问题讨论】：
“只是为了澄清数字不应包括已完成的故事”
知道了。
“或者将来‘可能’分成多个故事的故事。”
什么？这是我们积压的一半。
官方待办事项中总是有 5 ± 2 个故事，因为我们的产品负责人的大脑可以处理的就是这些。当我们完成一些时，还有一些会在最后加上“好吧，我们可能也想看看这个。”
作为架构师，我可以预见到另外 5 ± 2 层更具管理性、技术性的故事。
这些是我们积压的前 9 个故事。
此外，总是有定义模糊的故事“将来‘可能’分成多个故事”。有趣的是，这些数字似乎是 5 ± 2。
其中有 3 或 4 个，具体取决于您的“'可能'被分成多个故事”规则。
当然，除此之外，还有其他人想向我们讲述故事。例如，我们的销售人员有 5 ± 2 个故事是他希望看到的销售演示的一部分。它不是核心功能，而且含糊不清，而且“'可能'被分成多个故事”，所以我想这不算数。
我认为这很重要，顺便说一句。每个故事都必须被追踪。变化，变异，崩溃，但不可能从“可能崩溃”中辨别“真实”。这就是对故事进行优先级排序的重点——模糊、大或定义不明确的概念可以作为待办事项进行跟踪，直到它们的优先级很低，以至于其他项目比未完成的待办事项更重要。
正确答案是（5 ± 2 个故事）× 利益相关者数量。
【讨论】：
如果你不考虑你提到的史诗，我会说你在一个 sprint 中完成的故事的两倍。我认为根据故事的大小和团队的规模，这将在 20 到 30 之间变化。
目前，我们有 7 个故事不属于待办事项的 sprint。但我们目前正在构建积压工作，所以没有太多参考。
【讨论】：
刚刚快速浏览了我们的问题跟踪器：我们每个 sprint 完成大约 15-20 个故事，并为接下来的 3 个 sprint 制定了粗略的计划/分配。未分配的积压部分往往在 10-20 之间。因此，我们完整的待办事项大约包含 50 到 100 个故事。我想这会有很大的不同，这取决于我们离发布有多近（目前我们有大约 4 个冲刺；通常的发布周期大约是 15 个冲刺）——只是为了给你一个粗略的估计“我们团队中的字符串长度”:)
【讨论】：
这真的取决于项目tbh。
对于未提交的积压；最低的项目大约是 5-10，最高的大约是 25-30。
sprint Backlogs 更加一致，通常每个春季大约有 7 个 backlog 项目（2 周 sprint）。
【讨论】：
一个好的经验法则是花费团队 5% 的时间来维护产品待办事项 - 对 1 到 2 个 sprint 的故事进行全面梳理。对于我的团队来说，这通常对应于大约 15 到 25 个故事。
【讨论】：
令人惊讶的是这些数字在海报之间的实际一致性。
对于 2 周的冲刺：3 - 7 个故事，具体取决于他们的重量。新功能的故事更多，构建或更改旧/现有功能时的故事更少。
每个项目积压的故事：总共 25 - 40 个？
【讨论】：