在工作中，我们使用 Scrum 和 Azure DevOps 来运行我们的冲刺。我们每天的站会/站会通常会超时，因为我们会在冲刺中检查每个产品积压项目 (PBI) 来讨论它，即使它是说“它还没有开始”。
在我们的一个 sprint 回顾中，我提出了一个想法，使用 PBI 状态作为表示和分组正在进行的项目的一种方式，并让 sprint 待办事项按 PBI 排序，首先是 Committed，然后是 Approved 个项目，用 Done底部的工作项目。
我们之前在另一个团队中使用过它，我们的站立是直截了当的。然而，在这个团队中，所有项目在被带入冲刺时都在冲刺计划中被标记为 Committed。您仍然可以根据任务是否正在进行来判断哪些项目正在运行，但是与在站立期间查看 PBI 状态相比，您必须检查任务才能知道这一点。
这是我的问题的来源。在我的建议之后，团队投票决定尝试一下，但我们的技术主管关闭了它，说“Scrum 流程不适合投票”并提到了 Azure DevOps 工作项状态及其含义。
我从 Scrum 指南 的摘录中提供了证据，并且 Scrum 仅指对冲刺目标的承诺，而不是具体规定工作项状态。
特别是我用粗体强调了句子，以支持我为什么我的建议不会破坏 Scrum 的推理，我们应该试一试。
Scrum 很简单。按原样尝试并确定其哲学、理论和结构是否有助于实现目标和创造价值。 Scrum 框架故意不完整，只定义了实施 Scrum 理论所需的部分。 Scrum 建立在使用它的人的集体智慧之上。 Scrum 的规则不是为人们提供详细的说明，而是指导他们的关系和互动。
可以在框架内采用各种过程、技术和方法。
不管怎样，你们这些有过分热心的Tech Leads的人可能认为他们说什么就是什么，不管任何推理，所以我想我来这里问问专家是怎么说的。
TL;DR - 在冲刺中标记为 Approved 的项目会破坏 Scrum 并且敏捷世界会被烧毁吗？ （有点讽刺，但这是有效争论的内容。）
感谢您的任何意见/建议。
我是 Microsoft DevOps MVP 和认证培训师。由于流程是在 Azure DevOps 中集中配置的，更改它们有时会弄乱报告（有些不能按顺序更改，因为它们具有特殊含义），我可以理解为什么人们会在更改工作项状态时犹豫不决。
我做了很多 Azure DevOps 的迁移/升级，升级后修复流程和面板是很多工作，在过去可能会变得非常混乱。
所以，从技术角度来看，我明白了。
我也是一名专业的 Scrum 培训师，在 Scrum 指南中我们没有任何地方定义工作项的状态。我们想要的是团队让工作及其状态可见。如果看板不能反映工作的实际状态，它的用处就会大打折扣。因此，我们的建议是为您的董事会选择与您的工作方式相匹配的专栏。
幸运的是，在 Azure Boards 中，您可以非常轻松地配置产品积压看板，并添加不直接映射到不同状态的列。通过这种方式，您可以拥有跨不同团队的通用且易于理解的流程（Azure DevOps 定义的 Scrum 流程），但仍然拥有您自己的自定义列，每个列都映射到顶级工作项状态之一。
这样你就可以在你的产品待办列表板上添加你的承诺（我个人将其重命名为预测）和批准的列，并将这两个状态映射到底层 Scrum 流程模板中的“进行中”。
PS：过去，Scrum 的规范性更强。在较早的 Scrum 指南中，我们实际上更详细地描述了冲刺板。以前有几个推荐栏目：
| new | approved | committed | in progress | done |
他们的意思：