3 to 5 persons is nice. Above 7, standing meeting does not work anymore.
2) You do a round of the "standard 3 questions".
When one person is talking, other can answer and pairs can form at this moment. For instance I say "I will work on story A, and I want somebody to help me with Ruby on Rails", and then another person can say "I will do that with you, right after the standup meeting". When the turn comes to this other person, she will say "I did that... and I will work today with Bernard, as we just agreed".
The main objective is to create pairs of persons who will work together on same tasks.
3) You then review the task board, ensuring you covered the main point during the standup meeting. You can maybe adjust what you said, if needed.
When I leave the standup, I want to feel like I know exactly where we're at it in the sprint and that we are on top of the top priority tasks.
Daily standups are not exactly meant for this.
You want to discuss on what to work and with what priority in the Planning Meeting for the Sprint and you start working on them in the priority order. You need to use a issue tracker to know where you are at in the sprint and see how the team is doing.
It seems that you are the manager of the team or are trying to micromanage the team. This is not allowed in Scrum.
In Scrum the team decides on what it should work. I understand your concerns that the team may fail to deliver what it committed for the Sprint, but to make a successful self-organizing team you have to let it fail once. You should not be afraid of the failure and team should not be afraid to be punished.
Since you are using Scrum for only a few month, there's a high probability that the team will over-commit. If the burn down chart will show that the team will not be able to complete all items selected for the sprint, the Product Owner should help team to decide what items should be dropped. Here is a chance to drop less important ones.
Once again - if you will force team to select tasks according to the priorities during the sprint, you will kill the Scrum.
This is a very simple change which I've been making for a while now.
This is what I learnt yesterday
This is what I hope to learn today
I need some help to learn this.
Everything else should be visible on the board / charts already (blockers go on red stickies).
By valuing learning, we end up passing around information that's truly new to at least some of the people on the team, and we create an environment in which it's safe not to know everything, so learning can take place.
Does anyone have any experience with this sort of issue and have any better solutions?
I have read some articles about this kind of a topic - When Team members give zombie like answers to the 3 questions, when there is very little collaboration and synchronization, when everyone talks about their individual tasks but not about their dependencies, when Team members don't offer to suggest a solution to another Team members task after hearing their update, when everyone gives their status report to the SM and not the rest of the Team, you know that your Daily Scrum meeting is losing it's effectiveness.
Why would the above things be happening to a Scrum Team? Well, it could be because the SM follows a "command and control" on the Team, or your Team is not motivated enough, or the Team believes the Daily Scrum meeting is a waste of time, or the Team does not like collaborating and so on.
From the sound of the way you described your problem and commented on some other members answers, I think your real problem is "Command and Control". You have to allow self empowerment. You have to let go of the Team members but hold on to Scrum principles. Leave collaboration to the Team, don't force collaboration. Tasks should not be "assigned to" a developer as quoted by you, the team members should decide this on their own. The Team members would lose motivation if you try to control them, hence the dysfunctional Stand up meeting IMHO.
I think the goal of Scrum is to identify blocking issues and who needs to talk to who to resolve them. Are you using story/task cards? Progress can be assessed at a glance if you are....
发布评论
评论（6）
效果很好的方面：
1) 与
3 到 5 人的小团队合作很好。 7点以上，站着开会就不行了。
2) 您做一轮“标准 3 个问题”。
当一个人说话时，其他人可以回答，此时可以结对。例如，我说“我将处理故事 A，并且我希望有人帮助我处理 Ruby on Rails”，然后另一个人可以说“我将在站立会议后立即与您一起完成该任务”。当轮到另一个人时，她会说“我做到了……今天我将和伯纳德一起工作，正如我们刚刚商定的那样”。
主要目标是建立能够一起完成相同任务的人员。
3) 然后，您查看任务板，确保您在站立会议期间涵盖了要点。如果需要的话，你也许可以调整你所说的内容。
所有这一切大约需要 15 分钟
希望这会有所帮助。
What have seen working quite well:
1) Work with small team
3 to 5 persons is nice. Above 7, standing meeting does not work anymore.
2) You do a round of the "standard 3 questions".
When one person is talking, other can answer and pairs can form at this moment. For instance I say "I will work on story A, and I want somebody to help me with Ruby on Rails", and then another person can say "I will do that with you, right after the standup meeting". When the turn comes to this other person, she will say "I did that... and I will work today with Bernard, as we just agreed".
The main objective is to create pairs of persons who will work together on same tasks.
3) You then review the task board, ensuring you covered the main point during the standup meeting. You can maybe adjust what you said, if needed.
All this take about 15 minutes
Hope this help.
每日站立会议并不完全是为了这个目的。
您想在冲刺计划会议上讨论要做什么以及优先级如何，然后您开始按优先级顺序处理它们。 您需要使用问题跟踪器来了解您在冲刺中的进度并了解团队的表现。
Daily standups are not exactly meant for this.
You want to discuss on what to work and with what priority in the Planning Meeting for the Sprint and you start working on them in the priority order. You need to use a issue tracker to know where you are at in the sprint and see how the team is doing.
燃尽图应该显示您的进度。
您似乎是团队的经理，或者正在尝试对团队进行微观管理。这在 Scrum 中是不允许的。
在 Scrum 中，团队决定它应该做什么。我理解您担心团队可能无法兑现其对 Sprint 的承诺，但要打造一支成功的自组织团队，您必须让它失败一次。你不应该害怕失败，团队也不应该害怕受到惩罚。
由于您只使用 Scrum 几个月，因此团队很可能会过度投入。如果燃尽图显示团队无法完成为冲刺选择的所有项目，那么产品负责人应该帮助团队决定应该放弃哪些项目。这是一个放弃不太重要的事情的机会。
再说一遍——如果你在冲刺期间强迫团队根据优先级选择任务，你就会扼杀 Scrum。
Burn down chart should show you the progress.
It seems that you are the manager of the team or are trying to micromanage the team. This is not allowed in Scrum.
In Scrum the team decides on what it should work. I understand your concerns that the team may fail to deliver what it committed for the Sprint, but to make a successful self-organizing team you have to let it fail once. You should not be afraid of the failure and team should not be afraid to be punished.
Since you are using Scrum for only a few month, there's a high probability that the team will over-commit. If the burn down chart will show that the team will not be able to complete all items selected for the sprint, the Product Owner should help team to decide what items should be dropped. Here is a chance to drop less important ones.
Once again - if you will force team to select tasks according to the priorities during the sprint, you will kill the Scrum.
这是一个非常简单的改变，我已经做了一段时间了。
其他所有内容都应该已经在图板/图表上可见（阻止者会在红色便签上显示）。
通过重视学习，我们最终会向团队中的至少一些人传递真正新鲜的信息，并且我们创造了一个安全的环境，在这个环境中，不必了解所有事情，这样学习就可以发生。
This is a very simple change which I've been making for a while now.
Everything else should be visible on the board / charts already (blockers go on red stickies).
By valuing learning, we end up passing around information that's truly new to at least some of the people on the team, and we create an environment in which it's safe not to know everything, so learning can take place.
我读过一些关于此类主题的文章 - 当团队成员对 3 个问题给出僵尸般的答案时，当协作和同步很少时，当每个人都谈论他们的个人任务但不谈论他们的依赖关系时，当团队成员不这样做时在听到其他团队成员的更新后，不要向他们的任务提供解决方案建议，当每个人向 SM 而不是团队其他成员提供状态报告时，您就知道您的每日 Scrum 会议正在失去有效性。
为什么 Scrum 团队会发生上述事情？嗯，这可能是因为 SM 对团队遵循“命令和控制”，或者你的团队没有足够的积极性，或者团队认为每日 Scrum 会议是浪费时间，或者团队不喜欢协作等等在。
从您描述问题的方式以及对其他一些成员答案的评论来看，我认为您真正的问题是“命令与控制”。你必须允许自我赋权。你必须放弃团队成员，但坚持 Scrum 原则。将协作留给团队，不要强迫协作。任务不应像您引用的那样“分配给”开发人员，团队成员应自行决定。如果你试图控制团队成员，他们就会失去动力，因此恕我直言，站立会议功能失调。
I have read some articles about this kind of a topic - When Team members give zombie like answers to the 3 questions, when there is very little collaboration and synchronization, when everyone talks about their individual tasks but not about their dependencies, when Team members don't offer to suggest a solution to another Team members task after hearing their update, when everyone gives their status report to the SM and not the rest of the Team, you know that your Daily Scrum meeting is losing it's effectiveness.
Why would the above things be happening to a Scrum Team? Well, it could be because the SM follows a "command and control" on the Team, or your Team is not motivated enough, or the Team believes the Daily Scrum meeting is a waste of time, or the Team does not like collaborating and so on.
From the sound of the way you described your problem and commented on some other members answers, I think your real problem is "Command and Control". You have to allow self empowerment. You have to let go of the Team members but hold on to Scrum principles. Leave collaboration to the Team, don't force collaboration. Tasks should not be "assigned to" a developer as quoted by you, the team members should decide this on their own. The Team members would lose motivation if you try to control them, hence the dysfunctional Stand up meeting IMHO.
我认为 Scrum 的目标是识别阻塞问题以及谁需要与谁交谈来解决这些问题。您使用故事/任务卡吗？如果您是……，则可以一目了然地评估进度。
I think the goal of Scrum is to identify blocking issues and who needs to talk to who to resolve them. Are you using story/task cards? Progress can be assessed at a glance if you are....