我们正在尝试 Scrum :) 我们的故事是我从需求角度编写的面向用户的故事。这意味着可能不止一个人会致力于这个故事来完成任务。 我们还在流程中使用 JIRA 来管理票证和看板来监控进度。 门票以故事点进行估算，并根据完成故事的整体工作复杂性进行估算。 在冲刺计划会议期间，我们需要以某种方式计划下一个冲刺的工作。 我遇到的这些问题是可行的，并且确定如何通过此设置来做到这一点，因此我要求社区根据您的经验或意见提供反馈。
如果您可以在这里描述您的流程并解决我的一些问题。
我希望我能够对其他流程获得一些有价值的见解，这可以帮助我们尝试其中一些流程并弄清楚该怎么做。
我将分享我的团队使用的流程，但请记住，没有一条规则，最终您可以使用最适合您的团队的流程。
- 将故事分配给谁？因为会有多人参与吗？
分配给开发人员，整个团队主要致力于该故事。如果他们需要其他开发人员的帮助，他们可以为他们的工作添加子任务。如果最初假设需要许多开发人员来完成它，您可能需要考虑将故事分解为更小的故事。
- 我如何知道冲刺中需要多少个故事点？
这取决于开发人员的可用性和他们的 PTO 以及可能出现的支持/计划外工作的数量，还要考虑冲刺期间可能占用他们时间的会议。每个开发人员的得分取决于他们完成冲刺工作的能力，并将其合并为总数。假设您有 3 名开发人员，1 分是 2 周冲刺中的一天工作，其中一名开发人员休假一周。你的冲刺可能是这样的：
Dev 1: 10 points
Dev 2: 10 points
Dev 3: 5 points (-5 points week vacation)
-----------------
Sprint 25 points
- 我们可以创建子任务并将它们分配给一个人，但是子任务不会有 SP，所以我仍然看不到这个人有多少。
我们的团队在数小时内完成子任务点，并将故事和任务的总数分开。
- 另外，溢出门票怎么样？你会降低故事点吗？降低什么点？
我们创建一个重复的工单，并关闭当前冲刺中的工单和故事点，并根据剩余的内容降低该点。我们将名称更新为
[Continued] {Story Name}我要求的是有关工作流程的反馈，你是如何做到的？
每次冲刺后我们都会召开团队回顾会议。尝试最适合您团队的方法，并根据冲刺的进展情况听取反馈。根据团队反馈调整您的流程。