从团队技术负责人到Scrum Master或PO，我们需要从做决策转为提问题。
一、2个关于估算的问题
团队需要进行粗略的估算，但这并不是要求软队成员一定按照估算的结果执行。
问题一：估算结果的单位是小时、天、星期还是月？
这些时间有时候是重叠的，比如5个星期的估算值肯定比一个月的估算值长。但如果从团队成员那里得到“只要几个星期”的估算结果，这通常已经足够做决策了，这就需要团队重新做出更加准备的工作估算。
问题二：成员对按照估算完成有多大的信心？
团队进行估算时，我们真正要发现的其实是团队成员是否赞成这个估算结果以及对此抱有多大的信心。如果团队内超过90%的人对估算值充满信心，那么估算值更具有可行性。
二、3个关于团队决策的问题
Scrum Master或PO在了解一个团队如何做决定通常会考虑几个问题：
- 我们在做决定前还考虑过其他选项吗？
- 如果我们继续按此方向进行，可能发生的最糟糕的情况是什么？
- 我们需要做些什么才能让这个决定成为最佳决策？
这三个问题并不是每次团队决策都要问，设计这些问题的初衷是发现团队成员的不同见解。因为当问到第三个问题时候，会有人回答“所有事情”。这就会导致在项目执行过程中出现问题。
三、2个关于开会的问题
问题一：在场的各位都需要参加会议吗？
我们需要思考：如果缺少一两个人，会议是否还能继续？许多敏捷团队过于追求团队协作，团队成员总会觉得无论什么会议都需要他参加，甚至与他根本无关的会议。
Scrum Master一方面需要感谢他们对协同工作的用心，另一方面需要需要建立相应的团队规范，明确告知他们不需要出席每一场会议。
如果团队成员在会议中不能创造价值或者没有任何收获，那么他参加这场会议就是无意义的。为了防止上述规定被滥用，这里需要注意一点：这并不代表团队成员可以选择是否参加这场会议，而且团队作为一个整体是有权否决某个成员不愿意参加某个会议的想法。
第二个问题：除了在场的成员，还需要其他人参与会议吗？
这是为了确定是否有人缺席会议。有些会议的重要性要求必须所有人到场，这些会议需要有更多合适的参与者来产生更多价值。
四、1个“闲逛”时提的问题
传统的走动式管理是即便成为Scrum Master后仍花费大量的时间在交流上。举个例子，程序员和测试员在进行重要的谈话，这时Scrum Master可能会走过去旁听他们在说什么，并给出一些具有参考性的建议。但我们要知道并不是每次谈话都需要我们参与，尤其是他们看起来像是在讨论私事。
有时候，团队成员之间的探讨是有意义的，比如技术决策者应该了解程序员和测试怎么做决定。我们需要自问：这件事有必要让其他人知道吗？如果答案是肯定的，那我会尽量找到需要知道这件事的人，将信息同步给他。
五、1个在每日站会时提的问题
在每日站会中，Scrum Master或PO看到团队的迭代燃尽图，然后想知道他们如何在计划的迭代结束时完成所有任务。但当问同一个团队是都能够完成所有任务时候，他们的回答通常都是肯定的。
这时候，团队可能会出现预测不符合现实的情况，Scrum Master就需要团队成员思考：我应该了解些我不知道的内容？
Scrum Master可能得到“某个成员没有更新工时”“进度目前虽然落后但很快会赶上来”等各种答案，询问一些团队成员都知道但我所不知道的事情，这能够为同步“假设”提供很好的机会。
这个问题能够展现出众多不同的假设，从而找到出现问题的真实原因，以便大家达成一致，共同在迭代结束前完成所有任务。
总结
提问比陈述更能说明问题。 刚开始成为一名Scrum Master可能还没有发现提问的作用，有可能会错过了解团队和他们工作内容的机会。希望发现这些问题的作用！
