"Just to clarify the number should not include completed stories"
Got that.
"or stories which 'might' be broken into multiple stories in the future."
What? That's half our backlog.
There's always 5 ± 2 stories in the official backlog, because that's about all our product owner's brain can handle. When we finish a few, some more get tacked on the end as "well, we might want to look at this, too."
As architect, I can foresee an additional 5 ± 2 stories of a more administrative, technical nature.
Those are the top 9 stories in our backlog.
Plus there are always the vaguely defined stories "which 'might' be broken into multiple stories in the future." Interestingly, these appear to number 5 ± 2.
There are 3 or 4 of these, depending on your "'might' be broken into multiple stories" rule.
Beyond that, of course, additional people would like to throw stories at us. For example, our sales guy has 5 ± 2 stories that are part of a sales demo he'd like to see. It isn't core functionality, and it's vague and it "'might' be broken into multiple stories", so I guess it doesn't count.
I think it counts, BTW. Every story must be tracked. The change and mutate and get broken down, but it's impossible to discern "real" from "might get broken down". That's the point of prioritizing the stories -- vague or large or ill-defined notions can be tracked as backlog until they get so low priority that other projects are more important than the outstanding backlog.
The correct answer is (5 ± 2 stories) × number of stakeholders.
If you don't consider epics as you mentioned, I would say twice as much stories as you complete during one sprint. I think that will varie between 20-30 according to the size of the stories and the size of the team.
Currently we have 7 stories that aren't part of a sprint in the backlog. But we're currently building the backlog, so not much of a reference.
just had a quick look at our issue tracker: we complete about 15-20 stories per sprint and have a rough plan/assignment for the next 3 sprints. the unassigned backlog portion tends to be between 10-20. our complete backlog thus contains roughly between 50 and 100 stories. i guess this will vary quite a bit, depending on how close we are to a release (currently we have about 4 sprints to go; a usual release cycle is about 15 sprints long) -- just to give you a rough estimate on the "length of the piece of string" in our team :)
A good rule of thumb is to spend 5% of the team's time maintaining the product backlog - having 1 to 2 sprints worth of stories fully groomed. For my teams this usually corresponds to around 15 to 25 stories.
It's surprising how consistent these numbers actually are between posters.
For 2 week sprints: 3 - 7 stories, depending on their weight. More stories if its new functionality, less stories when building or changing old/existing functionality.
发布评论
评论（6）
“只是为了澄清这个数字不应该包括已完成的故事”
明白了。
“或者将来‘可能’被分解成多个故事的故事。”
什么？ 这是我们积压的一半。
官方待办事项中总是有 5 ± 2 个故事，因为这几乎是我们产品负责人的大脑所能处理的。 当我们完成一些后，更多的会被添加到最后，“好吧，我们可能也想看看这个。”
作为建筑师，我可以预见额外的 5 ± 2 层更具行政性和技术性。
这些是我们待办事项中排名前 9 的故事。
另外，总有一些定义模糊的故事“将来可能会被分解成多个故事”。 有趣的是，这些似乎有 5 ± 2 个。
其中有 3 或 4 个，具体取决于您的“可能”被分解为多个故事的规则。
除此之外，当然还有更多的人愿意向我们讲述故事。 例如，我们的销售人员有 5 ± 2 个故事，这些故事是他希望看到的销售演示的一部分。 它不是核心功能，而且它很模糊，并且“可能”被分成多个故事”，所以我想它不算数。
顺便说一句，我认为这很重要。 每个故事都必须被追踪。 变化、变异、崩溃，但不可能区分“真实”和“可能崩溃”。 这就是对故事进行优先级排序的要点——模糊、大或定义不明确的概念可以作为积压进行跟踪，直到它们的优先级如此之低以至于其他项目比未完成的积压更重要。
正确答案是（5 ± 2 层）× 利益相关者数量。
"Just to clarify the number should not include completed stories"
Got that.
"or stories which 'might' be broken into multiple stories in the future."
What? That's half our backlog.
There's always 5 ± 2 stories in the official backlog, because that's about all our product owner's brain can handle. When we finish a few, some more get tacked on the end as "well, we might want to look at this, too."
As architect, I can foresee an additional 5 ± 2 stories of a more administrative, technical nature.
Those are the top 9 stories in our backlog.
Plus there are always the vaguely defined stories "which 'might' be broken into multiple stories in the future." Interestingly, these appear to number 5 ± 2.
There are 3 or 4 of these, depending on your "'might' be broken into multiple stories" rule.
Beyond that, of course, additional people would like to throw stories at us. For example, our sales guy has 5 ± 2 stories that are part of a sales demo he'd like to see. It isn't core functionality, and it's vague and it "'might' be broken into multiple stories", so I guess it doesn't count.
I think it counts, BTW. Every story must be tracked. The change and mutate and get broken down, but it's impossible to discern "real" from "might get broken down". That's the point of prioritizing the stories -- vague or large or ill-defined notions can be tracked as backlog until they get so low priority that other projects are more important than the outstanding backlog.
The correct answer is (5 ± 2 stories) × number of stakeholders.
如果您不考虑您提到的史诗，我会说您在一次冲刺期间完成的故事数量的两倍。 我认为根据故事的大小和团队的规模，这个数字会在 20-30 之间变化。
目前，我们有 7 个故事不属于待办事项中的冲刺。 但我们目前正在构建积压工作，因此没有太多参考价值。
If you don't consider epics as you mentioned, I would say twice as much stories as you complete during one sprint. I think that will varie between 20-30 according to the size of the stories and the size of the team.
Currently we have 7 stories that aren't part of a sprint in the backlog. But we're currently building the backlog, so not much of a reference.
刚刚快速浏览了我们的问题跟踪器：我们在每个冲刺中完成大约 15-20 个故事，并为接下来的 3 个冲刺制定了粗略的计划/任务。 未分配的积压部分往往在 10-20 之间。 因此，我们完整的积压工作大约包含 50 到 100 个故事。 我想这会有所不同，具体取决于我们距离发布有多远（目前我们还有大约 4 个冲刺；通常的发布周期约为 15 个冲刺）——只是为了给您一个粗略的估计“我们团队中“绳子的长度”:)
just had a quick look at our issue tracker: we complete about 15-20 stories per sprint and have a rough plan/assignment for the next 3 sprints. the unassigned backlog portion tends to be between 10-20. our complete backlog thus contains roughly between 50 and 100 stories. i guess this will vary quite a bit, depending on how close we are to a release (currently we have about 4 sprints to go; a usual release cycle is about 15 sprints long) -- just to give you a rough estimate on the "length of the piece of string" in our team :)
这确实取决于项目。
对于未承诺的积压； 最低的项目约为 5-10，最高的项目约为 25-30。
冲刺待办事项更加一致，通常每个春季大约有 7 个待办事项（2 周冲刺）。
It really depends on the project tbh.
For the uncommited backlog; on the lowest projects it's about 5-10, and the highest it's about 25-30.
The sprint Backlogs are more consistent and generally have about 7 backlog items per spring (2 week sprints).
一个好的经验法则是花费团队 5% 的时间来维护产品积压工作——对 1 到 2 个冲刺的故事进行充分的整理。 对于我的团队来说，这通常对应于大约 15 到 25 个故事。
A good rule of thumb is to spend 5% of the team's time maintaining the product backlog - having 1 to 2 sprints worth of stories fully groomed. For my teams this usually corresponds to around 15 to 25 stories.
令人惊讶的是，这些数字在海报之间实际上是多么一致。
对于 2 周的冲刺：3 - 7 个故事，具体取决于故事的重量。 如果有新功能，则需要更多故事；如果构建或更改旧/现有功能，则需要较少故事。
每个项目积压的故事：总共 25 - 40 个？
It's surprising how consistent these numbers actually are between posters.
For 2 week sprints: 3 - 7 stories, depending on their weight. More stories if its new functionality, less stories when building or changing old/existing functionality.
Backlog'ed stories per project: 25 - 40 total?