Refinement meeting的召开是为了澄清细化需求，以提高planning meeting的效率，确保下个迭代可以交付最有价值的功能，当产品或需求复杂时可以考虑定期召开多次的refinement meeting以及线下讨论，以确保下个迭代的顺利进行。
Refinement meeting上PO与团队共同梳理team的product backlog，根据story的业务价值由高到低，需求由明确到不太明确，故事拆分由细到粗。同时提出未识别到的依赖，根据team的建议调整backlog优先级，调整验收标准（AC），团队玩牌估算故事点。
但不是refinement meeting上讨论的所有story都一定会进下个迭代，虽然高优先级的story几乎肯定会做，团队在下个迭代会commit多少story通常是根据估算在planning meeting上共同确定的。由于Scrummaster阿光所在的产品及团队的特殊性，在planning meeting前的最后一次refinement meeting上共同进行了下个sprint的commitment。（PS：对于不同团队或不同时期，为践行敏捷实践平稳落地，可能对敏捷框架进行本土化调整。）
但这并不是本文的重点，重点是阿光所在的团队这次commit过程异常顺利，在资深开发阿汪的带头commit下，其他成员纷纷积极commit story并确定交付送测的时间点，即使有个业务价值特别大的需求临时提出还不是特别清晰（虽然不推荐不鼓励），团队也可以做到这样：
PO to 测试：这个story估计下个sprint可以测完吗？
测试：开发能完成测试就能完成
阿光 to 前端：开发可能完成吗？
前端：后端能完成前端就能完成
阿光 to 后端：后端？
后端：需求清晰了后端就能完成
阿光 to BA：需求估计什么时候？
BA：明天上午我的工作就能做完
此时所有人都满脸期待地看着我们的SA（SystemAnalyst）
SA：我明天下班前完成
整个过程一分钟，在愉快轻松的氛围下快速达成commitment，PO很满意，团队很开心，阿光偷着乐。
团队在形成过程中逐步建立积极的氛围，建立信任及尊重，每个冲刺制定目标的仪式感及完成目标的成就感会带领团队逐步成为一只能快速反应并积极作战的特种部队，让我们共同期待！
