下面是我对于 Scrum 的学习、理解及总结，参考了 Scrum 指南和一些书籍，并加入了自己的一些理解，希望对自己有用。
Scrum 是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum 的三大支柱支撑起每个经验过程控制的实现。
第一大支柱是高透明度
高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明，而且那些被观察到的方面也必须被充分了解。这就是说，当某人检验某个过程并认为完成了某些任务时，这个完成必须等同于他们的完成定义。
第二大支柱是检验
开发过程中的各方面必须做到经常性的检验，以确保及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能允许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和勤勉程度。
第三大支柱是适应
如果检验员经检验发现过程中的一个或多个方面不满足可接受标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。
Scrum 中有三个进行检验和适应的时刻： 每日例会是用来检验朝向 Sprint 目标的工作进程，调整以优化次日的工作价值。另外，Sprint 评审和计划会议是用来检验朝向发布目标的工作进程，调整以优化下一个Sprint 的价值。最后，Sprint 回顾会议是用来评审完成的 Sprint，并确定什么样的调整可以使下一 Sprint 的效率更高、结果更令人满意和更易于工作。
Scrum 团队的目标是提高灵活性和生产能力。
敏捷价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
“敏捷开发”一词源自《敏捷宣言》。
Scrum 角色(Scrum Roles)：
流程经理(Scrum Master)：ScrumMaster 负责确保 Scrum 团队遵守 Scrum 价值、实践和规则；帮助 Scrum 团队和整个组织采用 Scrum；通过指导和引导，教授 Scrum 团队更高效工作、生产出高质量的产品；帮助 Scrum 团队理解并采用自组织和跨职能。
产品负责人(Product Owner)：产品负责人是管理产品待办事项列表、确保团队工作价值的唯一责任人。
团队(Scrum Team)：开发人员组成的团队负责在每个 Sprint 将产品待办事项列表转化成为潜在可交付的功能增量。
团队的 Team Leader 就是 ScrumMaster。团队的理想规模是7(±2)人。产品负责人和 ScrumMaster 这两个角色不计入成员人数，除非他们也是“猪”。Scrum 团队成员被称为“猪”。产品负责人是产品待办事项列表的“猪”。团队是 Sprint 任务的“猪”。ScrumMaster 是 Scrum 过程的“猪”。其他人被称为“鸡”。“鸡”没有权利要求“猪”如何去开展工作。
“鸡”和“猪”的比喻来自于以下的故事：
一只鸡对一头猪说：“我们合伙开家饭店吧！”猪想了想，说：“那我们给这个饭店起什么名字呢？”鸡说：“鸡蛋和火腿！”猪回答到：“那还是算了吧，你要做的只是下几只鸡蛋，我把命都搭上了！”
时间盒(Time-Box)：
| 发布计划会议(Release Planning Meeting) | |
| 目标 | 发布计划会议的目的是建立 Scrum 团队与组织内的其他部门能够理解和沟通的计划和目标。 |
| 主持人 | 产品负责人 |
| 参与者 | ScrumMaster、团队全体成员 |
| 时间 | 通常不超过组织构建传统发布计划的15-20%时间 |
| 地点 | 会议室 |
| 准备 | 与 Sprint 计划会议相同 |
| 成果 | 发布目标 具有最高优先级的产品待办事项列表 重大风险 发布所包含的全部特性和功能 确立大致交付日期和费用 |
| 主要内容 | 发布计划会议需要回答以下两个问题：“我们如何以最佳方式将愿景转化为成功的产品？我们怎样才能达到或甚至超越客户的满意度和投资回报？” 与 Sprint 计划会议基本类似，只是范围不同，而估算也会比较粗略。 |
| 日程安排 | 没有既定日程安排，主要看产品的实际情况而定。 |
| 其他 | 定义验收标准时，可以根据重要性区分“必须发布”、“应该发布”和“可缓发布”等不同等级。 关于时间估算，应该对最重要的条目进行时间估算，应该由团队来做估算，估算只是粗略估算不是承诺，不要花太多时间。单位为故事点，具体可以参看 Sprint 计划会议部分说明。 关于生产率估算，可以参看 Sprint 计划会议部分说明。确定重要性、发布等级、时间估算、生产率估算后就可以排定发布计划，类似如下图所示：  其中生产率估算为 45 个故事点，每个 Sprint 的时间估算合计不超过该生产率估算。最后可以增加一些时间缓冲，以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。 关于调整发布计划，每个 Sprint 之后，我们都要看一下这个 Sprint 的实际生产率。如果实际生产率跟估算生产率差距很大，我们就会给下面的 Sprint 调整生产率，更新发布计划。如果这会给我们带来麻烦，产品负责人就会跟客户进行谈判；或者检查一下是否能够在不违反合同的情况下调整范围；或者他跟团队一起找出一些方法，通过消除某些在 Sprint 中发现的严重障碍，提高生产率或是投入程度。 组合使用 Scrum 和极限编程(XP)会有显著收获，Scrum 注重的是管理和组织实践，而 XP 关注的是实际的编程实践，它们解决的是不同领域的问题，可以互为补充，相得益彰。与 XP 相关的有结对编程(Pair Programming)、测试驱动开发(TDD)、增量设计、持续集成、代码集体所有权、充满信息的工作空间、代码标准、可持续的开发速度/精力充沛的工作。 关于在 Sprint 中需要完成的非编程性任务的例子：搭建测试环境。明确需求。与运营部门讨论部署的操作细节。编写部署文档（版本说明，RFC，或任何在你们组织中要写的东西）。和外界的资源进行联系（例如 GUI 设计师）。改进构建脚本。将故事进一步拆分成任务。标识出来自开发人员的核心问题，并帮助解决这些问题。 关于 Sprint 后反馈的 Bug 的处理，可以在下一个 Sprint 中把“将旧功能产品化”分配高优先级。 |
| Sprint | |
| 目标 | 团队将 Sprint 待办事项列表转化成为可交付的功能增量。 一个 Sprint 就是一个迭代，Sprint 是以时间盒限定的。在 Sprint 中，ScrumMaster 负责确保不出现任何影响 Sprint 目标的变化。 |
| 主持人 | ScrumMaster |
| 参与者 | 团队全体成员 |
| 时间 | 2 周 ~ 4 周，一般 3 周比较适中 |
| 地点 | 团队最好能够在独立房间中坐在一起工作，避免外界干扰 |
| 准备 | Sprint 计划会议结束后 |
| 成果 | 完成 Sprint 目标 产品增量 经验积累 |
| 主要内容 | Sprint 计划会议 开发工作 每日例会 Sprint 评审会议 Sprint 回顾会议 |
| 日程安排 | 周一 09:00 – 17:00 Sprint 计划会议 平日 10:00 – 10:15 每日例会 周四 09:00 – 12:00 Sprint 评审会议 周四 14:00 – 16:15 Sprint 回顾会议 周五 实验日 |
| 其他 | 关于实验日，可以在两个 Sprint 之间设定 1 天实验日，让大家可以放松一下，可以做任何他想做的事情，比如研习最新的工具和 API、准备认证、跟同事讨论乱七八糟的事情、开发自己喜欢的项目，等等。这样你就能得到自然的休息，开发团队也能让自己了解最前沿的知识。这也是一种能够吸引员工的福利。例如安排周四进行 Sprint 评审会议和 Sprint 回顾会议，周五为实验日，下周一进行下一轮的 Sprint 计划会议。 如果团队发现承诺的任务过多，可以和产品负责人沟通，以减小 Sprint 中选定的产品待办事项列表范围。如果团队发现有富余的时间，可以和产品负责人商议追加额外的产品待办事项列表。 |
| Sprint 计划会议(Sprint Planning Meeting) | |
| 目标 | Sprint 计划会议制定迭代计划。举办 Sprint 计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。 |
| 主持人 | 产品负责人 |
| 参与者 | ScrumMaster、团队全体成员 |
| 时间 | 3 周的 Sprint 对应 6 小时，在 Sprint 开始的时候 |
| 地点 | 会议室 |
| 准备 | 在 Sprint 计划会议之前，要确保产品待办事项列表的井然有序： 产品待办事项列表必须存在。 只能有一个产品待办事项列表和一个产品负责人（对于一个产品而言）。 所有重要的 Backlog 条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。 产品负责人应当理解每个故事的含义（通常故事都是由他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序）。他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里。 产品负责人之外的人也可以向产品 Backlog 中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。 |
| 成果 | Sprint 目标 Sprint 演示时间、地点 经过团队认可、要添加到这个 Sprint 中的故事列表 Sprint 中每个故事的估算值 Sprint 中每个故事的“如何演示” 生产率和资源计算，用作 Sprint 计划的现实核查。包括团队成员的名单、投入程度及每个人的承诺（不然就没法计算生产率） 明确每日例会固定举行的时间地点 把故事拆分成任务 |
| 主要内容 | 第一部分中决定 Sprint 需要做什么。第二部分团队研究在 Sprint 内如何将功能构建成产品增量。 每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖。范围(Scope)和重要性(Importance)由产品负责人设置。估算(Estimate)由团队设置。在 Sprint 计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。 会议启动以后，产品负责人一般会先概括一下希望在这个 Sprint 中达成的目标，还有他认为最重要的故事。接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。在这个过程中，他们会针对范围提出些重要问题：“‘删除用户’这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答复会让他们感到惊讶，促使他们调整估算。 在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法不太一样。这可能会让他调整故事的重要性；或者修改故事的范围，或者对故事进行分拆，导致团队重新估算，然后一连串诸如此类的后续反应。 关于质量，我们分为内部质量和外部质量。外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。我把外部质量也看作范围的一部分。产品负责人必须弄清楚内部质量是不可能让步的，他一般都会处理好其他变量。 |
| 日程安排 | 09:00 – 17:00 （每小时休息 10 分钟，中午休息 2 小时） 09:00 – 12:00 第一部分：做什么 09:00 – 09:30 产品负责人对 Sprint 目标进行总体介绍，概括产品待办事项列表。定下演示的时间、地点。 09:30 – 11:00 团队估算时间，在必要的情况下拆分 Backlog 条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 Backlog 条目都要填写“如何演示”。 11:00 – 12:00 团队选择要放入 Sprint 中的故事。计算生产率，用作核查工作安排的基础。 12:00 – 14:00 午餐、休息 14:00 – 17:00 第二部分：怎么做 14:00 – 17:00 为每日例会安排固定的时间、地点（如果和上次不同的话）。把故事进一步拆分成任务。 |
| 其他 | 关于估算值，可以每人给定一些牌（包括：0,1/2,1,2,3,5,8,13,20,40,100,?,咖啡），每人均要对故事进行估算并同时亮牌，通过即时沟通逐渐让团队估算趋于一致。 关于生产率，估算生产率(Estimated velocity) = 可用人天(Available man-days) * 投入程度(Focus factor)，根据历史数据计算：投入程度 = 实际生产率(Actual velocity) / 可用人天，默认投入程度：70%。可用人天是所有团队成员在本次 Sprint 中可以高效的、不受打扰的投入开发的天数总和。 关于技术故事，指的是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值的故事。例如：安装持续构建服务器、编写系统设计概览、重构 DAO 层、升级 Bug 跟踪工具等。试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。产品负责人能看到它，但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商，从 Sprint 里拨出一些时间来完成这些技术故事。 |
| Sprint 评审会议(Sprint Review) | |
| 目标 | Sprint 末尾时要举行 Sprint 评审会议，一个月的 Sprint 通常对应 4 小时时间盒的评审会议。评审会议又称为演示会议，这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作。 |
| 主持人 | 产品负责人 |
| 参与者 | ScrumMaster、团队全体成员、相关干系人（非必须）、组织其他人员（非必须） |
| 时间 | 3 周的 Sprint 对应 3 小时 |
| 地点 | 会议室 |
| 准备 | Sprint 中完成的故事 Sprint 中遇到的问题及如何解决 |
| 成果 | 演示会议的意义： 团队的成果得到认可。他们会感觉很好。 其他人可以了解你的团队在做些什么。 演示可以吸引相关干系人的注意，并得到重要反馈。 演示是（或者说应该是）一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。 做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中）。如果没有演示，我们就会总是得到些 99% 完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。这（在我们的案例中）比得到一堆貌似完成的工作要好得多，而且后者还会污染下一个 Sprint。 |
| 主要内容 | 产品负责人确定完成了哪些工作和剩余哪些工作。 团队讨论在 Sprint 中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。 团队演示完成的工作并答疑。 产品负责人和与会人员讨论产品待办事项列表，并根据不同的速率计划出可能的完成日期。 整个团体就哪些工作已经完成，同时这对下一步工作有何意义进行探讨。 Sprint 评审会议为接下来的 Sprint 计划会议提供了宝贵的参考信息。 |
| 日程安排 | 这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作。下面的日程安排只是一种模拟。 09:00 – 12:00 （每小时休息 10 分钟） 09:00 – 11:00 团队逐一演示每个已经完成的用户故事。 11:00 – 11:30 团队讨论遇到的问题和如何解决，并进行答疑。 11:30 – 12:00 产品负责人确定完成了哪些工作，并和与会人员讨论产品待办事项列表。 |
| 其他 | Sprint 演示检查列表： 确保清晰阐述了 Sprint 目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。 节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。 让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。 可能的话，让观众自己试一下产品。 不要演示一大堆细碎的 bug 修复和微不足道的特性。你可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事。 |
| Sprint 回顾会议(Sprint Retrospective) | |
| 目标 | 旨在对前一个 Sprint 周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。 |
| 主持人 | ScrumMaster |
| 参与者 | 产品负责人、团队全体成员、相关干系人（非必须）、组织其他人员（非必须） |
| 时间 | 3 周的 Sprint 对应 2 小时 15 分钟，一般是 1 ~ 3 小时，在 Sprint 评审会议结束之后和下个 Sprint 计划会议之前。 |
| 地点 | 一个能够在不受干扰的地方。一般不会在团队房间中进行回顾，因为这往往会分散大家的注意力。 |
| 准备 | 需要演示的内容 Sprint 中遇到的问题及解决办法 Sprint 中做得好的地方 Sprint 中需要改进的地方及改进方法 |
| 成果 | 将要在下个 Sprint 中实现的有效改进方法。 哪些做法可以保持 哪些做法需要改进 如何改进的具体想法 我们怎样才能在下个 Sprint 中做的更好 |
| 主要内容 | 可以指定某人当秘书，记录会议内容。 ScrumMaster 向大家展示 Sprint 待办事项列表，在团队的帮助下对 Sprint 做总结。包括重要事件和决策等。 我们会轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个 Sprint 中改变。 我们对预估生产率和实际生产率进行比较。如果差异比较大的话，我们会分析原因。 快结束的时候，ScrumMaster 对具体建议进行总结，得出下个 Sprint 需要改进的地方。 团队通过头脑风暴得出所有的想法，写在即时贴上，然后用“圆点投票”来决定下一个 Sprint 会着重进行哪些改进。每个人都有三块小磁铁，投票决定下个 Sprint 所要采取措施的优先级。他们可以随意投票，也可以把全部三票投在一件事情上。 根据投票情况，他们选出了 5 项要重点进行的过程改进，在下一个回顾中，他们会跟踪这些改进的执行情况。 |
| 日程安排 | 14:00 – 16:15 （每小时休息 10 分钟） 14:00 – 14:30 ScrumMaster 在团队的帮助下对 Sprint 做总结。 14:30 – 15:30 大家轮流发言，提出需要保持的做法、需要改进的做法和如何改进的想法。 15:30 – 16:00 大家讨论及投票选出下一个 Sprint 会着重进行哪些改进。 16:00 – 16:15 ScrumMaster 对具体建议进行总结，得出下个 Sprint 需要改进的地方。 |
| 其他 | 关于“知识桥梁”，有一个人会参加所有的 Sprint 回顾会议，充当知识桥梁。他需要服从一些重要规则： 他应当是一个很好的倾听者。 如果回顾会议过于沉寂，他应该问一些简单而目标明确的问题，以刺激团队展开讨论。例如“如果时间可以倒流，从第一天重新开始这个 Sprint，那你觉得哪些事情会用其它方式来做？” 他应该自愿花时间参加所有团队的全部回顾。 他应该有一定的行政权力，如果出现一些团队无法控制的改进建议，他可以帮助推进实施。 |
| 每日例会(Daily Scrum) | |
| 目标 | 团队每天进行 15 分钟的检验和适应的会议就称为 Scrum 每日例会。 |
| 主持人 | ScrumMaster |
| 参与者 | 团队全体成员 |
| 时间 | 15 分钟，一般选择大家都能接受的最早的时间。 |
| 地点 | 任务板前 |
| 准备 | 已经完成的任务、准备进行的任务、工作中的障碍 |
| 成果 | 增加新任务 更新任务板 更新 Sprint 待办事项列表 更新 Sprint 燃尽图 解决工作中的障碍 |
| 主要内容 | 每日例会在各个 Sprint 都是在同一时间，同一地点进行。会议上，每个团队成员需要汇报以下三个问题： 1. 从上次会议到现在都完成了哪些工作； 2. 下次每日例会之前准备完成什么； 3. 工作中遇到了哪些障碍。 |
| 日程安排 | 10:00 – 10:15 团队成员轮流发言 |
| 其他 | 关于迟到，可以设定规则，无论任何理由（除了预先请假并获得批准）迟到，每迟到 1 分钟捐献 1 元（上限可以设定 50 元）存入团队基金，供团队活动使用。 关于“我不知道今天干什么”，首先可以让团队成员过一遍任务板，明确目标、故事、任务，发现需要做的事情。然后检验目标是否已经达成，如果已经达成可增加故事到 Sprint 中，如果未达成通常可以发现新任务。最后可以采用其他方法，例如下面的做法： 羞辱式做法：“如果你不知道怎么帮助团队，我建议你还是回家去，或者看书，或者怎么都行。要不也可以找个地方坐下，等别人需要帮忙的时候你就过去。” 守旧式做法：简单给他们分配个任务了事。 施加同事压力的做法：对他们说，“Joe，还有 Lisa，你们两个可以放松点，我们会站在这里慢慢等，直到你们找到帮助我们完成目标的事情为止。” 奴役式做法：对他们说，“你们今天可以给大伙儿干干杂活。倒咖啡、做按摩、清理垃圾、做午饭，一切一切大家今天让你们做的事情。”你会惊讶的发现 Joe 和 Lisa 在霎那之间就找出了有用的技术任务 :o) 如果团队成员不太重要，可以考虑调离团队；如果团队成员比较重要，可以考虑让他与其他团队成员结对。 |
工件(Artifact)：
| 产品待办事项列表(Product Backlog) | |
| 用途 | 产品待办事项列表列出团队正在开发的产品需求。产品负责人负责产品待办事项列表的内容、可用性和优先级。 |
| 所有者 | 产品负责人 |
| 读者 | ScrumMaster、团队全体成员、相关干系人（非必须）、组织其他人员（非必须） |
| 时间 | Sprint 计划会议后更新 |
| 主要内容 | 列表中的条目以用户故事的形式展现。 产品负责人了解所有的用户故事。 产品负责人只需要关注业务目标，如何解决问题的应该是开发团队。 产品待办事项列表中包含产品开发和交付成功产品需要的所有条件和因素。表中列出了所有的特性、功能、技术、改进方法和故障修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、优先级和估算的特征。优先级是以风险、价值和必要性驱动的。 |
| 主要的故事字段： | |
| ID | 统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。 |
| 名称 Name | 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由 2 到 10 个字组成。 |
| 重要性 Importance | 产品负责人评出一个数值，指示这个故事有多重要。例如 10 或 150。分数越高越重要。 |
| 初始估算 Initial estimate | 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点(story point)，一般大致相当于一个“理想的人天(man-day)”。 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半） 一般每个故事控制在 2~8 个故事点，太小会引发微观管理，太大会导致承诺不足或过度承诺，需要进行拆分。 |
| 如何做演示 How to demo | 它大略描述了这个故事应该如何在 Sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。 |
| 注解 Notes | 相关信息、解释说明和对其它资料的引用等等。一般都非常简短。 |
| 额外的故事字段： | |
| 类别 Track | 当前故事的大致分类，例如“后台系统”或“优化”。这样产品负责人就可以很容易选出所有的“优化”条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。 |
| 组件 Components | 通常在 Excel 文档中用“复选框”实现，例如“数据库，服务器，客户端”。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个 Scrum 团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。 |
| 请求者 Requestor | 产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。 |
| Bug 跟踪 ID Bug tracking ID | 如果你有个 Bug 跟踪系统，那么了解一下故事与 Bug 之间的直接联系就会对你很有帮助。 |
发布燃尽图(Release Burndown)：发布燃尽图记录了在一段时间内产品待办事项列表的总剩余估算工作量。估算工作量以 Scrum 团队和组织决定的单位为标准，时间是以 Sprint 为单位。
| Sprint 待办事项列表(Sprint Backlog) | |
| 用途 | Sprint 待办事项列表包含团队需要执行的任务，从而将产品待办事项列表条目转化成“完成”的增量。 |
| 所有者 | |
| 读者 | |
| 时间 | Sprint 计划会议之后，第一次每日例会之前创建完成 |
| 主要内容 | |
| 主要的故事字段： | |
| ID | 统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。 |
| 名称 Name | 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由 2 到 10 个字组成。 |
| 重要性 Importance | 产品负责人评出一个数值，指示这个故事有多重要。例如 10 或 150。分数越高越重要。 |
| 初始估算 Initial estimate | 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点(story point)，一般大致相当于一个“理想的人天(man-day)”。 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半） 一般每个故事控制在 2~8 个故事点，太大的需要进行拆分。 |
| 如何做演示 How to demo | 它大略描述了这个故事应该如何在 Sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。 |
| 注解 Notes | 相关信息、解释说明和对其它资料的引用等等。一般都非常简短。 |
| 额外的故事字段： | |
| 类别 Track | 当前故事的大致分类，例如“后台系统”或“优化”。这样产品负责人就可以很容易选出所有的“优化”条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。 |
| 组件 Components | 通常在 Excel 文档中用“复选框”实现，例如“数据库，服务器，客户端”。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个 Scrum 团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。 |
| 请求者 Requestor | 产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。 |
| Bug 跟踪 ID Bug tracking ID | 如果你有个 Bug 跟踪系统，那么了解一下故事与 Bug 之间的直接联系就会对你很有帮助。 |
Sprint 燃尽图(Sprint Burndown)：Sprint 待办事项列表燃尽图展现的是当前 Sprint 内剩余的 Sprint 待办事项列表工作数量。创建该图需要通过累计 Sprint 中每日待办事项列表估算来确定剩余工作量。
规则(Rule)：将 Scrum 的时间盒、角色和工件联系起来。
完成(Done)：Scrum 的一个规则是关于每个 Sprint 目标的，即严格按照“完成”的定义开发潜在可交付的产品增量。Scrum 要求团队在每个 Sprint 内构建产品功能的增量。这个增量必须是潜在可交付的，因为产品负责人可能会要求立即实现该功能。为了做到这一点，增量必须是最终产品完整的一部分，必须是“完成”的。每个增量都必须可以和前面所有增量累加起来，并且进行过彻底的测试，以保证所有的增量能兼容工作。
参考：
Scrum 指南下载地址：http://www.scrum.org/scrumguides/
Scrum 官方网站：http://www.scrum.org
硝烟中的 Scrum 和 XP 我们如何实施 Scrum
MSF for Agile Software Development 5.0 版