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