团队举行了第一次Planning Meeting，有产品经理（PO）、TEAM（研发+测试）还有Scrum Master参与。

Meeting有个三环节：

第一、确定Sprint周期和团队可用故事点 —— 2周，80SP（Story Point）

第二、从需求池（Backlog）中筛选To Do的Story，这个环节由PO讲解每个Story，对TEAM的疑问进行解答 —— 这个环节需要PO会前事先准备好需要的Story，并确定好优先级。

由于我们第一次Planning Meeting，所以这个环节占用大量时间来确定To Do的Story和排优先级。

第三、根据优先级，对每个Story进行扑克牌评估（如果如上环节PO事先准备好，则这个环节在评估之前需要逐一讲解）。

我们是这样评估的，TEAM出牌，PO出牌但仅供参考，出现偏差较大，由最大最低点着进行PK，如果达成一致，则评估SP为达成一致值，如果不能，则重新出牌，二次出牌扔不能达成一致，由PO决定。

如此这样循环，直到达到团队可用的故事点（根据上次SP进行估算），由于我们没有上次经验，所以我们将本次需求都进行评估。

补充：如果第二个Sprint开始后，可以根据第一次Sprint的SP进行估值，如果超过这个LSP，则团队可能不能按时完成任务。

会议结束后，就形成了我们的故事版，我们的第一次冲刺Sprint开始了。

我们向PO承诺，在2周的Sprint内完成这些Story，根据默认的优先级进行开发，每周有2个上线日，我们定义为里程碑。我们在上个里程碑结束后确定下个里程碑的交付，就是小迭代。

产品经理向我们承诺在迭代内，不添加新需求，期间遇到紧急情况或日常琐碎的事情，包括上线，都记做Buffer（缓冲）。

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然)  ©著作权归作者所有