使用这种方式的好处是显而易见的，它能让所有人对这个故事点有一个共识，这意味着，不管谁来完成这个用户故事，那么他是认可这个故事点的。而且它可以有效的避免不假思索的跟风行为，每个人必须对用户故事的复杂度进行思考，才能给出一个相对可靠的故事点，否则就要向所有人进行解释。
使用这种方式也有它的弊端，那就是计划会议非常耗时。在实践中，有的团队将估算的环节放在计划会议之前，而有的团队不借助扑克牌，而是直接通过全员讨论得出一个相对正确的故事点。
T团队对于用户故事的估算是需要不断的磨合的，同时还有一个需要不断磨合的是团队速度。A君B君C君已经在计划会议中为若干个用户故事完成了估算，总故事点约为40，那么T团队能够完成这个40个故事点吗？实践是检验猜测的唯一方式。
随着几个迭代的尝试，T团队发现30个故事点的工作量刚刚好，不紧也不慢，那么T团队的团队速度即为30个故事点/10天。
团队速度的作用之一是，如果T团队在一个迭代中规划了总计为30个故事点的用户故事，不管每个用户故事是A君B君C君谁来做，理论上这些用户故事T团队都能按时完成。当然T团队的速度不是一成不变的，下图是我所在的团队最近三个迭代的团队速度。
（截图来自Worktile Agile）
根据过去一段时间的团队速度来规划下一个迭代的工作规模，是非常科学的。
T团队对自己团队的能力有着清晰的认识，也对迭代的目标充满着信心。另外，T团队还可以根据自己的团队速度，在迭代中插入一定比例的非功能性需求。
除了团队速度，使用故事点也可以非常直观的体现T团队在一个迭代中的工作进展，下图是我所在的团队Sprint 10的燃尽图。
（截图来自Worktile Agile）
燃尽图的趋势可以有效的体现T团队目前是否失控，如果燃尽图总是居高不下，所有人需要在站立会议中进行讨论，共同发现、承担并解决问题，这才能称得上是一个团队，不是吗？