“只是为了澄清这个数字不应该包括已完成的故事”
了解。
“或者将来‘可能’分成多个故事的故事。”
什么？这是我们积压的一半。
官方积压中总是有 5 ± 2 个故事，因为这是我们产品负责人的大脑所能处理的全部内容。当我们完成一些时，最后会加上一些“好吧，我们可能也想看看这个”。
作为架构师，我可以预见另外 5 ± 2 个更具管理性、技术性的故事。
这些是我们积压的前 9 个故事。
另外，总是有定义模糊的故事“将来‘可能’分成多个故事”。有趣的是，这些似乎是 5 ± 2。
其中有 3 或 4 个，具体取决于您的“'可能'被分成多个故事”规则。
当然，除此之外，还有其他人想向我们讲述故事。例如，我们的销售人员有 5 ± 2 个故事是他希望看到的销售演示的一部分。它不是核心功能，而且含糊不清，而且“'可能'被分成多个故事”，所以我想这不算数。
我认为这很重要，顺便说一句。每个故事都必须被追踪。变化，变异，崩溃，但不可能从“可能崩溃”中辨别“真实”。这就是故事优先级的重点——模糊、大或定义不明确的概念可以作为积压工作进行跟踪，直到它们的优先级很低，以至于其他项目比未完成的积压工作更重要。
正确答案是（5 ± 2 个故事）× 利益相关者数量。
如果你不考虑你提到的史诗，我会说你在一个冲刺中完成的故事的两倍。我认为根据故事的大小和团队的规模，这将在 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 个？