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