我们已经使用 Scrum 几个月了，我从未觉得我从站立会议中获得了巨大的价值。当我离开站立会议时，我想感觉自己确切地知道我们在冲刺中处于什么位置，并且我们处于最优先任务的首位。
我们做标准的三个问题，但是因为我们是面对面的，所以没有关于实际用户故事的位置的真正对话，因为多个人同时在处理它。
对于最近的 sprint，我们尝试了颠倒格式并按优先级顺序查看每个任务。如果每个人正在处理该任务，则每个人都会根据该任务回答三个问题。这让我们更好地了解每项任务的当前状态，并确保我们正在做正确的事情......
有没有人对这类问题有任何经验并有更好的解决方案？
【问题讨论】：
效果很好：
1) 与小团队合作
3 到 5 人很好。超过 7 人，常设会议不再起作用。
2) 你做了一轮“标准 3 题”。
当一个人说话时，其他人可以回答，此时可以结对。例如，我说“我将处理故事 A，我希望有人帮助我使用 Ruby on Rails”，然后另一个人可以说“我会和你一起做，就在站立会议之后”。当轮到另一个人时，她会说“我做到了……今天我将和伯纳德一起工作，正如我们刚刚商定的那样”。
主要目标是创建能够共同完成相同任务的人。
3) 然后您查看任务板，确保您在站立会议期间涵盖了要点。如果需要，您可以调整您所说的内容。
这一切大约需要 15 分钟
希望对您有所帮助。
【讨论】：
当我离开站立会议时，我想 感觉就像我确切地知道我们在哪里 在冲刺中，我们正在 最优先的任务。
每日站会并不完全是为了这个。
您想在 Sprint 的计划会议上讨论工作内容和优先级，然后您开始按优先级顺序处理它们。 您需要使用问题跟踪器来了解您在 sprint 中的位置并了解团队的工作情况。
【讨论】：
燃尽图应该会显示进度。
您似乎是团队的经理，或者正在尝试对团队进行微观管理。这在 Scrum 中是不允许的。
在 Scrum 中，团队决定应该做什么。我理解您对团队可能无法交付其为 Sprint 承诺的内容的担忧，但要打造一个成功的自组织团队，您必须让它失败一次。你不应该害怕失败，团队不应该害怕受到惩罚。
由于您只使用了几个月的 Scrum，因此团队很可能会过度使用。如果燃尽图显示团队无法完成为 sprint 选择的所有项目，产品负责人应该帮助团队决定应该放弃哪些项目。这是一个放弃不太重要的机会。
再一次 - 如果您在 sprint 期间强制团队根据优先级选择任务，您将扼杀 Scrum。
【讨论】：
这是一个非常简单的改变，我已经做了一段时间了。
其他所有内容都应该已经在图板/图表上可见（阻止者在红色便签上显示）。
通过重视学习，我们最终向至少团队中的一些人传递了真正新的信息，并且我们创造了一个安全的环境，在这种环境中，不知道所有事情是安全的，因此可以进行学习。
【讨论】：
有没有人对这类问题有任何经验并有更好的解决方案？
我读过一些关于这类话题的文章——当团队成员对这 3 个问题给出僵尸般的答案时，当协作和同步很少时，当每个人都在谈论他们各自的任务而不是他们的依赖关系时，当团队成员在听到他们的更新后不会向其他团队成员的任务提出解决方案，当每个人都向 SM 而不是团队的其他成员提供他们的状态报告时，你知道你的每日 Scrum 会议正在失去它的有效性。
为什么上面的事情会发生在 Scrum 团队身上？嗯，可能是因为 SM 对团队遵循“命令和控制”，或者你的团队没有足够的动力，或者团队认为每日 Scrum 会议是浪费时间，或者团队不喜欢协作等等开。
从您描述问题和评论其他一些成员答案的方式来看，我认为您真正的问题是“命令和控制”。你必须允许自我赋权。你必须放开团队成员，但要坚持 Scrum 原则。将协作留给团队，不要强迫协作。不应将任务“分配给”您引用的开发人员，团队成员应自行决定。如果您试图控制团队成员，他们会失去动力，因此功能失调的站立会议恕我直言。
【讨论】：
我认为 Scrum 的目标是识别阻塞问题以及谁需要与谁交谈来解决这些问题。你在使用故事/任务卡吗？如果您是...，可以一目了然地评估进度。
【讨论】：