如何根据已知的团队能力计算第一次新开始的scrum的Sprint用户故事容量?

纠正上述问题

对于完全不熟悉敏捷scrum流程的scrum团队，如何根据已知的以小时为单位的团队能力，以用户故事点为单位计算第一个Sprint的Sprint用户故事容量?

用户故事1 = 1故事点

开发团队可能会估计实现用户故事1所需的时间。

数值是每个故事点的小时数。

虽然我知道每周的工作量是210小时，但是这个信息并不能帮助我在第一个sprint中决定用户故事的工作量，因为我只知道48个故事点的工作不能转换成小时，因为敏捷不建议这样做

比娜,

为什么您需要在开发团队决定他们可以在第一个sprint中预测的事情中扮演任何角色?作为一名Scrum Master，你应该尽可能多地帮助团队(即——能力和速度指标)，但最终还是由开发团队决定他们觉得自己能完成什么。

记住，我们说的是估计．敏捷不是关于完美，而是关于改进。从你的最佳猜测开始，并从那里开始，尝试在每个sprint中做出更好的估计和预测。

冲刺长度= ?

我很好奇，在时间框还没有确定的情况下，你的团队是如何做出预测的?

所以如果他们是scrum新手，我会在几次sprint中远离故事点。

我的直觉是，你和你的团队都不理解故事情节，你在制造自己的问题。

我个人很讨厌故事点。随着时间的推移，我会建立故事点，直到我能够评估团队获得sprint和时间盒等基本知识，我才会使用故事点。

你计算出来的能力并不等于你的团队可以完成的分数。人们一开始就混淆了容量不等于速度。

比娜，我建议你再读一遍scrum指南。你在问Scrum Master如何决定要处理的故事的数量，以及SM如何决定sprint的长度。SM完全没有权利做出这样的决定。Sprint长度由Scrum团队(产品负责人+ Scrum管理员+开发团队)决定，这是一个双方都同意的长度。公认的标准是2周，所以与你的团队讨论并将其作为一个选项。对于一个新组建的团队，我会说1周太短了，4周太长了，所以2周或3周可能是一个不错的中间值。在几次冲刺之后，作为一个团队来讨论决定的长度是否有效，或者是否应该进行调整。最坏的情况是，你把它改成不同的长度，但它不起作用;回到你所知道的有效方法。

至于开发团队要做的工作量，SM或PO没有发言权。开发团队决定他们要做什么，订单可以提供待办事项项的优先级级别，但如果开发团队决定选择30点或10点，这是他们在Scrum中的权利，没有人可以阻止。SM的作用只是鼓励团队在计划他们将要做的工作时考虑之前的sprint和考虑潜在的风险。我还认为你过于关注容量和速度的数字，并期望有一个数学公式，你可以应用它来找到每个sprint中使用的最佳故事点数量。Scrum是建立在经验主义的基础上的，也就是基于已知的东西来做决定。你正在寻找的计算似乎没有考虑到开发团队成员的经验水平或他们可用的工具或他们遇到的障碍。你能做的最好的事情就是支持你的团队，让他们做决定，你通过跟踪数据来帮助他们，这样以后就可以用它来检查和调整。即使你不同意团队的选择，也要支持他们。让它成为你和团队的学习时间。

假设你的团队决定进行3周的sprint，他们选择了45个故事点。在冲刺结束时，他们已经完成了25分;太棒了!未完成的项目返回到待办事项列表中，团队可以为下一个sprint选择它们。他们了解到，在那个时候，45个任务实在是太多了。下一个sprint他们选择25点，因为这是他们在前一个sprint中完成的点数。在冲刺的中途，他们完成了所有25分;太棒了!回到待办事项列表，选择更多的项目，在sprint的剩余时间里继续工作。团队现在有两个sprint的价值信息，他们可以进一步检查和调整。 The team can work and discuss together to determine what the variance was as to why they completed such different amount of story points within each sprint; was it an issue with capacity or competency or maybe an issue with story estimation? They continue on this cycle until they get a better understanding (through empiricism) proper story estimation, sprint planning, and based on the past they can make better decisions as a team.

Scrum的伟大之处在于能够不断地检查和调整。尝试一些短跑项目，然后作为一个团队讨论，并确定它是否对团队有帮助。团队喜欢吗?很好，继续用。团队讨厌它吗?太好了，别用了，找别的吧。这是一个新的团队，正如你所提到的，任何不“失败”的期望都是错误的。团队会失败，这是一件好事，因为他们学会了如何不做某事，这将防止或至少阻止未来类似的失败。

最后，摆脱你和团队对典型项目管理的所有想法。采取开放的思想和心态，对尝试新事物没有问题，对尝试和失败也没有问题。我最近了解了一些关于敏捷的Spotify方法，其中一件让我印象深刻的事情是他们对失败的感受;他们喜欢!为什么不过?因为他们发现了行不通的东西，这为未来提供了很好的信息，他们可以很容易地从失败中改进;比成功容易得多。

对于完全不熟悉敏捷scrum流程的scrum团队，如何根据已知的以小时为单位的团队能力，以用户故事点为单位计算第一个Sprint的Sprint用户故事容量?

在考虑能力和潜在的Sprint长度之前，开发团队是否具备:

-完成的定义是关于发布质量的?

-满足“完成”定义所需的所有技能和资源?

换句话说，在产品待办事项列表中是否存在团队在Sprint结束时无法完全开发、集成、测试并立即发布到生产环境中的描述?有什么工作是他们无法完全依靠自己的力量完成的吗?即使这个故事是唯一一个正在制作的故事，Sprint的时间被限制在一个月以内?

+ 1柯蒂斯。

@Ching-Pei Li，这是相对估计的错误应用。你不应该将一个小时数等同于一个故事点。如果你喜欢这样做，为什么不简单地减少浪费，用时间来代替呢?

故事点是相对的估计。想想t恤的尺寸(XL, L, M, S, XS)。只需要将物品放入适当大小的桶中即可。

你好,

如果我们只使用故事点，从不将故事点映射到时间，我们如何为一个固定价格的项目达成scrum项目(发布)的初始估计，并说服客户接受这个价格?

斯瓦米murty

你好,

如果我们只使用故事点，从不将故事点映射到时间，我们如何为一个固定价格的项目达成scrum项目(发布)的初始估计，并说服客户接受这个价格?

斯瓦米murty

团队是否有绩效历史(即速度)，可以据此预测交付日期?

请记住，敏捷/Scrum的设计主要是为了结合经验主义来响应变化。因此，敏捷项目的范围并不是真正“固定的”，即使目标交付日期可能是固定的。

唯一的问题是:

• 截止日期前将有多少原scope交付?
• 截止日期前将交付多少“新”范围?
• 有多少原始范围将被搁置或不交付?

请记住，如果团队从最关键的业务价值项目开始工作，那么任何没有交付或搁置的项目都应该没有什么业务价值

听起来你想确定两件事:

1. 团队可以估计他们将在sprint中完成多少工作
2. 交付一组用户描述需要多长时间?

以下是在我工作过的团队中行之有效的方法。

要确定团队可以在一个sprint中投入多少工作:

1. 选择一个要带入sprint的用户故事
2. 把团队需要做的工作分解成任务
3. 用小时值估算这些任务(即使是粗略的估算也可以)
4. 询问团队是否认为他们有足够的资源进行冲刺。如果没有，请重复步骤1。根据容量验证估计的小时数，作为一种感觉检查

注意这里这里没有提到故事点或速度．正如Mike Cohn(和其他人)所说，速度是衡量短期计划的一个糟糕指标。这对长期规划很有用。

要确定交付一组用户故事需要多长时间:

1. 确定团队的速度
2. 确定发布的用户描述的总描述点
3. 用总数除以速度得到冲刺数。

如果你没有速度(例如在Sprint 1的开始阶段)，你可以尝试以下几种方法:

• 使用团队带入Sprint 1的全部故事点，但要注意它可能非常不准确
• 根据团队在sprint中所投入的内容进行猜测
• 在Sprint 1完成之前，不要提供任何速度

这不是一个固定的规则，其他人可能不同意，但这对我来说是有效的，我在其他地方读到过。

如果我们只使用故事点，从不将故事点映射到时间，我们如何为一个固定价格的项目达成scrum项目(发布)的初始估计，并说服客户接受这个价格?

如果价格是固定的，而不是范围或时间，那么除了客户可以购买的sprint数量，还有什么可以计算的呢?

容量规划的目的是什么?我们如何为团队计算容量，如何将容量转换为小时数或故事点

容量规划和速度之间的差异