Scrum中的产出物
#Product Backlog——Backlog 待开发项，积压的任务。
产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。
#Sprint Backlog——Sprint 本意为“冲刺”，--也指的是本次要迭代需求，指迭代周期，长度通常是一至六周。
在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。
#User Story、Task——用户故事、任务
用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间按照小时估算
团队建设
•Scrum 团队最佳人数控制在“5～9”人。
•全职能性团队：开发组（UI、后台开发、前端开发、测试人员——4~8人）、Scrum Master（技术负责人或者核心）、产品负责人
•兼职团队成员：DBA、运维
通用会议规则
基本要求
•每次会议都要准时开始、准时结束。
•每次会议都采取开放形式，所有人都可以参加。
会前准备
•提前邀请所有必须参会的人，让他们有时间准备。
•发送带有会议目标和意图的会议纲要。
•预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
•会前24小时发送提醒。
•准备带有会议规则的挂图。
会议推进
•展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
•推进人展示会议的目标和意图。
•有必要时，推进人可以商定由某个撰写会议记录。
•推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。
•推进人会对会议进行收尾，并进行非常简短的回顾。
会议输出
•用记录文档，给白板和挂图上的内容拍照。
•必须传达会议记录和大家对会议结果的明确共同认知并发送相关钉钉群。
Sprint规划会议
会议目的
•该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
•产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。
一定要确定产品愿景价值：
为了：（目标客户）
谁：（需要）
这个：（产品名称）
是一个：（产品分类）
它：（产品的好处，购买的理由）
不同于：（竟品）
我们的产品：（差异、价值主张）
附加扩展：（是否符合公司的战略）基本要求
•迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
•只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。
构成部分：
•电脑投屏展示经过估算和排序的 Product Backlog。
•假期计划表、重要人员的详细联系信息。
•参会成员：团队成员、Scrum Master、产品负责人
持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。
会议输出
•选择好的 Product Backlog 条目。
•各个 Backlog 条目的需求。
•各个 Backlog 条目的用户验收测试。
会议过程
•从第一个 Product Backlog 条目（故事）开始。
•讨论该 Product Backlog 条目，以深入理解。
•分析、明确用户验收测试。
•找到非功能性需求（性能、稳定性...）
•找到验收条件。
•弄清楚需要“完成”到何种水平。
•获得 Backlog 条目各个方面的清晰了解。
•绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。
•回到步骤1，选取下一个 Backlog 条目。
注意事项：不要改变 Backlog 条目大小，不要估算任务。
估算会议
基本要求
•只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。
构成部分：
•Product Owner 根据业务价值排定 Product Backlog 各项顺序。
•需要参加的人员：Team、Product Owner、User、Scrum Master
注意事项：
•Product Owner 不参与估算。
会议过程
•Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
•团队使用规划扑克来估算 Backlog 条目。
•如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。
•重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。
持续时间：该会议时间限制为不超过60分钟。
会议输出
•经过估算的 Product Backlog。
•更小的 Backlog 条目。
扑克牌估算
具体步骤：
•每个人各自估算后独立出暗牌，听口令一起开牌。
•数值最大者与最小者PK，其他人旁听也可参考。
•讨论结束后重新出牌和开牌。
•重复上述过程，直到结果比较接近。
每日站立会（Daily Standup Meeting）
会议目的
•团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
•任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。
构成部分
•任务板、即时贴、马克笔
•提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。
基本要求
•成员：团队、Scrum Master
•无法出席的团队成员要由同伴代表。
•持续时间/举办地点：每天15分钟，同样时间，同样地点。
•提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”
会议输出
•团队彼此明确知道各自的工作，最新的工作进度图。
•得到最新的“障碍 Backlog”
•得到最新的“Sprint Backlog”
会议过程
•团队聚在故事板旁边，可以围成环形。
•从左边第一个开始，向团队伙伴说明他到现在完成的工作。
•然后该成员将任务板上的任务放到正确的列中。
•如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。
•如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
•每个团队成员重复步骤2到步骤5。
每个人三个问题：
•昨天完成的工作
•今天计划做的工作；
•面临什么阻碍，是否存在技术风险，需要什么帮助；
注意事项
•不要迟到
•不要超出限制时间
•不要讨论技术问题
•不要转变会议话题
•不要在没有准备的情况下参加
•Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。
•Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。
•如果不能出席会议，需要通知团队，并找一名代表参加。
任务板
•任务板集合了选择好的 Product Backlog 和 Sprint Backlog，并以可视化方式展示。
•任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
•尽量使用大白板，也可以使用软件。
任务板有4列：
•选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
•待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完成的新任务，并将它们放入该列。
•进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小 的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。
•完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡
如图所示：
燃尽图
•跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
•团队每天更新燃尽图。
•如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
•燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。
Sprint反思会议（Retrospective Meeting）
会议目的
•该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。
会议的目的是通过新的沟通形式唤起大家对团队的集体意识，指出团队或个人在一段时间内的不足并列出对应的行动。持续而有效的回顾和反馈，可以保证团队关心生产力和效率，了解团队自身的不足和问题，这将成为团队持续改进的起点。
回顾的关注点也多种多样，除了“项目开发”之外，还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时，需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化，不断调整回顾的关注点和形式，确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出，还能够不断提升团队内部的安全感和信任度。
构成部分
•参与人员：团队成员、Scrum Master
基本要求
•从过去中学习，指导将来。
•改进团队的生产力。
注意事项
•不要让管理层人员参与会议。
•不要在团队之外讨论找到的东西。
持续时间：60分钟内