冲刺 (sprint) 计划会议
在冲刺 (sprint) 的第一天，团队要在计划会议中确立冲刺 (sprint) 积压工作。 在此会议中，产品所有者会与团队协同工作，确定将在该冲刺 (sprint) 中完成哪些情景。 计划会议包含两个部分，每个部分的长度不超过会议长度的一半。 在会议的第一部分，您的团队和产品所有者根据以前的冲刺 (sprint) 体验来标识团队认为可承诺在冲刺 (sprint) 中完成的用户情景。 标识用户情景后，可使用“产品计划”工作簿将它们指派给冲刺 (sprint)。 有关更多信息，请参见“产品计划”工作簿。
在会议的第二部分，团队确定它将如何开发和测试这些用户情景。 然后，团队将这些用户情景分解为多个任务并估计完成它们所需的工作量。 最后，团队基于这些估计承诺实现全部或部分用户情景。
在会议的第一部分，产品所有者与团队会面，共同讨论可能要在冲刺 (sprint) 中包含的用户情景。 产品所有者将与团队共享有关这些情景的信息并回答团队提出的所有相关问题。 此会谈将会传递一些详细信息，如数据源、用户界面布局、响应时间预期以及安全性和可用性方面的考虑。 团队应向用户情景添加这些详细信息。 在此部分会议中，团队了解到必须生成的内容。
在团队讨论了认为必要的所有有关用户情景的详细信息之后，Scrum 主管将开始计划会议的第二部分。 产品所有者应关注会议的这一部分以帮助阐明要求，并帮助了解和选择替代项。 Scrum 主管在此部分会议中，帮助团队确定如何实现用户情景以及团队是否可承诺实现产品所有者要求的所有情景。 为了更好地了解完成每个用户情景所涉及的内容，团队将每个情景分解为多个任务，团队必须执行这些任务来实现相应情景并确保完成该情景。 冲刺 (sprint) 积压工作中的任务可能类似以下示例：“更新存储过程以使用新的数据源”和“为收集器 Web 服务创建类”。
团队可使用“迭代积压工作”工作簿将用户情景分解为任务。 有关更多信息，请参见“迭代积压工作”工作簿。
然后团队估计每个任务所需的工时数。 由于这些任务在完成估计之后才会被指派给成员，因此团队需要协同工作来得出这些估计值。 （在冲刺 (sprint) 计划会议期间，团队通常不能标识和估计所有工作。 团队在冲刺 (sprint) 期间完成的 40% 的工作是在冲刺 (sprint) 计划会议之后出现的）。
计划扑克方法是用于估计任务工时的好工具。 使用此工具，每个团队成员都可以参与估计，而不用依赖行业专家来估计团队成员各自的任务。 无论是使用这种方法还是另一种方法，都应调动整个团队来确定每个任务将花费的工时数。 有关更多信息，请参见以下 Web 资源：Planning Poker（计划扑克）。
任务的大小应为在一天内能够完成。 如果某个任务太大，则团队应将其分解。 在某些情况下，在完成其他任务之前可能无法有效估计一些任务。 此时创建任务，但在您了解足够信息时估计此任务。 将各个任务的估计工时相加即可确定团队完成每个用户情景可能需要的工时数。
团队继续分析每个用户情景并估计任务量，直到团队确定冲刺 (sprint) 中的情景已足够多。 团队在作出这一判断时，需要比较估计工时数与团队预期在冲刺 (sprint) 中投入的工时数。
可以使用“迭代积压工作”工作簿中的团队容量工作表，帮助确定用于冲刺 (sprint) 的团队容量。 必须在设置工作表中填写冲刺 (sprint) 的详细信息。 考虑到休假、假日和其他中断，还必须填写中断工作表。 有关更多信息，请参见“迭代积压工作”工作簿。
如果任务估计工时数超过了可用工时数，因而团队确定无法完成产品所有者要求的一个或多个情景，则应告知产品所有者。 产品所有者可能会将原有情景替换为较小的用户情景，也可能拆分情景，或将该情景保留在产品积压工作中，供在将来的冲刺 (sprint) 中完成。 团队完成计划会议的这两个部分之后，即已完成以下工作：
创建了冲刺 (sprint) 积压工作，并确定了每个用户情景的任务和工时
承诺完成将在该冲刺 (sprint) 中交付的用户情景
作为一个自我组织的团队，了解应如何协作以履行其承诺。