菜单
菜单
Scrum知识库全面介绍了Scrum的理念、角色、流程、工具使用等各方面的核心知识，旨在帮助您快速全面地了解和学习Scrum的知识体系。
Scrum是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周（互联网产品研发可以使用1周的Sprint）。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验，以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现：透明性、检验和适应。Scrum的三大支柱如下：
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
Scrum： Scrum无对应中文翻译
Agile： 敏捷
Lean： 精益
Iterative：迭代式的
Iteration：迭代
Agile Manifesto： 敏捷宣言
Empirical： 经验性的
Empirical Process：经验性过程
Transparency： 透明性
Inspect and Adapt： 检视与调整
Sprint：原意为冲刺，Scrum中的Sprint无对应中文翻译，指一个迭代
Sprint Goal：Sprint目标
Product Owner ：产品负责人，简称PO
Scrum Master ：简称SM，一般不翻译
Developers ：开发人员（Scrum团队中除了PO和SM之外的所有人）
Scrum Team：Scrum团队，含PO、SM和开发人员
Scrum Roles：Scrum角色，指PO、SM和开发人员
Emergent ：涌现的
Product Backlog：产品待办列表，指需求清单
Sprint Backlog：Sprint待办列表，指Sprint任务清单
Sprint Burn-down Chart：Sprint燃尽图，团队用于做Sprint内的进展跟踪
Release Burn-down Chart: 发布燃尽图，产品负责人做发布进展跟踪
Sprint Planning: Sprint计划会
Daily Scrum：每日站会
Sprint Review：Sprint评审会
Sprint Retrospective: Sprint回顾会
Product Backlog Refinement: 产品待办列表梳理
Product Backlog Item: 产品待办清单条目，简称PBI
User Story: 用户故事，指一条需求
Story Point：衡量用户故事的工作量大小的计量单位
Velocity: 团队速度
Sprint Task: 实现一条需求需要做的一个技术任务
Definition of Done: DoD，完成的定义
Stakeholders： 干系人
Backlog： 待办列表
Artifact ：工件
Estimation ：估算
Collaboration： 协作
Scaling Scrum：大规模Scrum
Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形。然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。
1986年，竹内弘高和野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发，他们指出：
传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。
敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和 野中郁次郎开发的知识管理策略。受到以上思想的影响，以及对世界范围内软件项目的研究，Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。
1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。
软件开发是一个复杂的活动， 在软件产品开发的过程中不仅存在着需求的不确定性，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。如下图所示，软件开发活动通常处在下图的很复杂的区域。
为了管理软件开发的活动，我们会引入过程控制来管理它。过程控制通常有两种方式，第一种方式是预定义的过程，第二种方式是经验性过程。
我们所熟知的是预定义的过程，它通常是使用已知的方法解决已知的问题。制造业的生产线就是典型的预定义过程，例如生产饼干、啤酒、汽车的生产线等。预定义的过程的特点是给予固定的输入，得到固定的输出，过程可重复。它的优势在于可以大规模批量生产。预定义过程的缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大的损失。
如果我们期望解决的问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。经验性过程的特点是过程是不能够完全预先定义好，结果是不可预知的，生产过程是不可重复的。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。
“在过程运行机制相当简单易懂的情况下，典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围，便应用经验性方式。”
——B.A.Ogunnaike and W.H.Ray
《过程动态学、建模与控制》
软件产品的研发通常存在多很多的不确定性，并且生产的过程非常的复杂，所以更适合使用经验性过程来管理。
Scrum以经验性过程控制理论做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日站会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
Scrum 的基本单位是小团队，称为 Scrum Team（Scrum团队）。 Scrum 团队由一名 Scrum Master，一名 Product Owner 和 Developers 组成。在 Scrum 团队中，没有子团队或层次结构。Scrum 团队是具有凝聚 力的专业团体，一次专注于一个目标，即 Product Goal。
Scrum 团队是跨职能的（cross-functional），这意味着团队成员具有在每个 Sprint 中创造价值而所需的全部技能。他们也是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。
Scrum 团队规模足够小以保持灵活，同时足够大以便可以在一个 Sprint 中完成重要的工作，通常只有 10 人或更少。总的来说，我们发现较小的团队沟通更好，效率更高。如果 Scrum 团队变得太大，则应考虑将他们重组为多个具有凝聚力的 Scrum 团队，每个团队都专注于同一产品。因此，他们应该共享相同的 Product Goal、Product Backlog 和 Product Owner。
Scrum 团队负责所有与产品相关的活动，包括与干系人的协作、验证、维护、运营、实验、 研究和开发，以及可能需要进行的其他任何活动。组织组建并授权 Scrum团队自行管理他们自己的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum 团队的专注度和一致性。
整个 Scrum 团队都有责任在每个 Sprint 中创建有价值的、有用的 Increment（增量）。 Scrum 在 Scrum 团队中定义了三种特定的职责：Developers、Product Owner 和 Scrum Master。
Developers（开发人员）不仅仅是负责开发软件的成员，这里指的是 Scrum 团队中致力于创建每个 Sprint 可用 Increment（增量） 的任何方面的人员。
Developers 所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。但是， Developers 始终要负责：
Product Owner（产品负责人）负责将 Scrum 团队的工作所产生的产品价值最大化。 如何做到这一点可能在组织、Scrum团队 和个体之间存在很大差异。 Product Owner 还负责对 Product Backlog 进行有效管理，包括：
Product Owner 可以自己做上述工作，或者也可以将职责委托他人。 然而无论如何， Product Owner 是负最终责任的人。
为保证 Product Owner 取得成功，整个组织必须尊重他们的决定。这些决定在 Product Backlog 的内容和顺序中可见，并在 Sprint Review 时透过可检视的 Increment 予以体现。
Product Owner 是一个人，而不是一个委员会。在 Product Backlog 中，Product Owner 可以代表许多干系人的期望要求。那些想要改变 Product Backlog 的人可以尝试去说服 Product Owner 来做到这一点。
Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum 团队 和组织内的每个人理解 Scrum 理论和实践来做到这一点。
Scrum Master 对 Scrum 团队的效能负责。他们通过让 Scrum 团队在 Scrum 框架内改进其实践来做到这一点。
Scrum Masters 是真正的领导者，服务于 Scrum 团队和作为更大范围的组织。
Scrum Master 以多种方式服务于 Scrum团队 ，包括：
Scrum Master 以多种方式服务于 Product Owner，包括：
Scrum Master 以多种方式服务于组织，包括：
Scrum 的工件代表工作或价值。它们旨在最大限度地提高关键信息的透明度。因此，为适应而检视它们的每个人对工件都有相同的基础。
每个工件都包含一个承诺，以确保它提供可增强透明度并聚焦于可度量进展的信息：
这些承诺的存在是为了强化经验主义和 Scrum Team 及其利益攸关者的 Scrum 价值观。
Product Backlog 是一份涌现的和有序的清单，它列出了改进产品所需的内容。它是 Scrum Team 所 承担工作的唯一来源。
能够被 Scrum 团队在一个 Sprint 中完成（Done）的 Product Backlog 条目被认为准备就绪，在 Sprint Planning 事件中可供选择。它们通常在精化活动后获得这种透明度。Product Backlog 精化是 将 Product Backlog 条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为 Product Backlog 条目增添细节，例如描述、优先顺序和规模。这些属性通常随工作领域而变化。
将要做这项工作的 Developers 负责使其适当的大小。Product Owner 可以通过帮助 Developers 理解和权衡取舍来影响他们。
Product Goal 描述了产品的未来状态，可以作为 Scrum 团队制定计划的目标。Product Goal 在 Product Backlog 中。Product Backlog 的其余部分涌现，用来定义“做什么”将实现 Product Goal。
产品是传递价值的载体。它具有明确的边界、已知的干系人和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。
Product Goal 是 Scrum 团队的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一 个目标。
Sprint Backlog 由 Sprint Goal （为什么做）、为 Sprint 选择的 Product Backlog 条目（做什么）以及交付 Increment 的可执行计划（如何做）组成。
Sprint Backlog 是 Developers 为其制定的计划。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多，Sprint Backlog 在整个 Sprint 期间会进行更新。它应该有足够的细节，以便他们可以在 Daily Scrum 中检视其进展。
Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。 Sprint Goal 还创造了连贯性和专注点，鼓励 Scrum 团队一起工作而不是分开独自行动。
Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当 Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与 Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次 Sprint Backlog 的范围。
Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。
在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能略微呈上升趋势。
在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。
一个 Increment 是迈向 Product Goal 的一块坚实垫脚石。每个 Increment 都是之前所有的 Increment 累加起来的，并经过彻底地验证，以确保整合在一起的所有 Increment 都能工作。为了提供价值，Increment 必须是可用的。
在一个 Sprint 中可以创建多个 Increment。 Increment 的总和在 Sprint Review 中展示，从而支持经验主义。 但是，Increment 可以在 Sprint 结束之前交付给干系人。Sprint Review 决不应该被视为发布价值的关口。
一项工作除非符合 Definition of Done ，否则不能将其视为 Increment 的一部分。
Definition of Done （完成的定义）是当 Increment 符合产品所需的质量度量标准时对其状态的正式描述。
当一个 Product Backlog 条目符合 Definition of Done 时，就会产生一个 Increment。
Definition of Done 通过使每一个人对作为 Increment 的一部分、什么样的工作算是已完成的工作有一个共同的理解来创建透明。如果一个 Product Backlog 条目不符合 Definition of Done，那么它就不能发布，甚至不能在 Sprint Review 中展示它。相反，它返回到 Product Backlog 中以供将来考虑。
如果 Increment 的 Definition of Done 是组织标准的一部分，那么所有 Scrum 团队都必须以此为最低标准来遵守。如果它不是组织标准的一部分，那么 Scrum 团队必须制定适合于该产品的 Definition of Done。
Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的 机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。 最理想的是，所有事件都在同一时间同一地点举行，以便减少复杂性。
Sprint 是 Scrum 的核心，在这里创意（idea）转化为价值。
它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。
实现 Product Goal 所需的所有工作，包括 Sprint Planning、Daily Scrum、Sprint Review 和 Sprint Retrospective，都发生在 Sprint 内。
在 Sprint 期间：
Sprint 通过确保至少每个日历月一次对达成 Product Goal 的进展进行检视和适应，来实现可预测性。当 Sprint 的长度拉得太长时，Sprint Goal 可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期，并将成本与工作投入（effort）的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。
存在各种各样的实践来预测进展，例如，燃尽图（burn-downs）、燃起图（burn-ups）或累积流图（cumulative flows）。尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决策。
如果 Sprint Goal 已过时，那么就可以取消 Sprint。只有 Product Owner 有取消 Sprint 的权力。
Sprint Planning 通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum 团队协作创建的。
Product Owner 要确保与会者准备好讨论最重要的 Product Backlog 条目 ，以及它们如何映射到 Product Goal 。Scrum 团队还可以邀请其他人参加 Sprint Planning 以提供建议。
Sprint Planning 处理以下话题：
话题一：为什么这次 Sprint 有价值？
Product Owner 提议产品如何在当前的 Sprint 中增加其价值和效用。然后，整个 Scrum 团队将共同制定一个 Sprint Goal ，用以沟通当前 Sprint 对干系人有价值的原因。必须在 Sprint Planning 结束之前最终确定 Sprint Goal 。
话题二：这次 Sprint 能完成（Done）什么？
通过与 Product Owner 讨论， Developers 从 Product Backlog 中选择一些条目，放入当前 Sprint 中。 Scrum 团队可以在此过程中精化这些 Product Backlog 条目，从而增加理解和信心。
选择在 Sprint 中可以完成多少任务可能会有挑战。 但是，Developers 对他们以往的表现，他们在即将到来的 Sprint 内的产能以及对他们的 Definition of Done 了解得越多，他们对 Sprint 预测就越有信心。
话题三：如何完成所选的工作？
对于每个选定的 Product Backlog 条目，Developers 都会规划必要的工作，以便创建符合 Definition of Done 的 Increment。这通常是通过将 Product Backlog 条目分解为一天或更短的较小条目来完成的。Developers 自行决定如何完成这一工作。没有人告诉他们如何将 Product Backlog 条目转化为价值的 Increment。
Sprint Goal 、这次 Sprint 所选出的 Product Backlog 条目加上如何交付它们的计划称之为 Sprint Backlog。
Sprint Planning 是有时间盒限定的，以一个月的 Sprint 来说最多为 8 个小时。对于更短的 Sprint， Sprint Planning 所需时间通常会更短。
Daily Scrum 的目的是检视达成 Sprint Goal 的进展，并根据需要调整适应 Sprint Backlog，以调整即将进行的计划工作。
Daily Scrum 是一个属于 Scrum 团队的 Developers 的 15 分钟的事件。为了降低复杂性，它在 Sprint 的每个工作日都在同一时间同一地点举行。如果 Product Owner 或 Scrum Master 正在积极处理 Sprint Backlog 条目，那么他们将作为 Developers 参与其中。
Developers 可以选择他们想要的任何举行 Daily Scrum 的结构和技术，只要他们专注于实现 Sprint Goal 的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。
Daily Scrum 改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。
Daily Scrum 并不是唯一一次允许 Developers 调整计划的时间。他们可以在一天中任何时间碰面，详细讨论如何调整适应或重新规划 Sprint 的剩余工作。
Sprint Review （Sprint 评审会）的目的是检视 Sprint 的成果并确定未来的适应性。Scrum 团队向关键干系人展示他们的工作结果，并讨论 Product Goal 的进展情况。
在 Sprint Review 期间，Scrum 团队和干系人将评审在这次 Sprint 中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。Product Backlog 也可能会进行调整以适应新的机会。Sprint Review 是一个工作会议，Scrum 团队应避免将其仅限于展示。
Sprint Review 是 Sprint 的倒数第二个事件，Sprint Review 是有时间盒限定的，以一个月的 Sprint 来说，最多为 4 个小时。 对于更短的 Sprint，Sprint Review 通常所需的时间更短。
Sprint Retrospective（Sprint回顾会）的目的是规划提高质量和效能的方法。
Scrum 团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的 Definition of Done 的情况如何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设，并探究其起源。Scrum 团队讨论在 Sprint 期间哪些进展顺利，遭遇到哪些问题以及这些问题是如何解决（或未解决）的。
Scrum 团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个 Sprint 的 Sprint Backlog 中。
Sprint Retrospective 结束 Sprint。它是有时间盒限定的，以一个月的 Sprint 来说，最多为 3 个小时。对于更短的 Sprint，Sprint Retrospective 通常所需的时间更短。
Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：
承诺， 专注， 开放， 尊重和勇气
Scrum 团队致力于达成其目标并且相互支持。他们的主要关注点是 Sprint 的工作，以便尽可能地向着这些目标获取最好的进展。Scrum 团队及其干系人对工作和挑战持开放态度。Scrum 团队成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。Scrum 团队成员有勇气做正确的事并处理那些棘手的问题。
这些价值观为 Scrum 团队的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用 Scrum 的方式应强化这些价值观，而不是削弱或破坏它们。Scrum 团队成员通过 Scrum 事件和工件来学习和探索这些价值观。当 Scrum 团队和与他们一起工作的人们体现这些价值观时，基于经验主义的 Scrum 的三个支柱：透明、检视和适应，就成为现实，并在每个人之间构建信任。
在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。
增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。
在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发人员。
我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的开发人员，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。
Scrum的开发人员对实现Sprint目标需要做的所有事情负责，包括技术方案和决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织的团队，他们也对他们的工作进度的跟踪和管理负责。Scrum开发人员的主要职责包括如下五个方面：
自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。
对于经理领导的团队来说，团队成员被分配任务，团队成员只有执行任务的权利。
对于经理领导的团队来说，管理者除了要确定目标、方向，团队的上下文（组织结构、团队结构、团队组成），还需要监督和管理团队的过程和进度，分配任务即确定谁做什么。这种团队的管理方式，更多的是命令与控制，以及微观管理。
一个自组织的团队通常由不同职能专业、思考方式和行为模式的成员组成，也就是说它是跨职能的团队。
自组织的团队不是与生俱来的，打造一个团队需要一个过程，打造一个组织团队也是一样。打造自组织团队，首先要让团队需要完全自主； 其次，有了自主，管理者需要引导团队持续改进，帮助团队持续地挑战更高的目标；第三，给团队提供环境和支持，引导团队往正确地方向迈进。
如果我们的产品开发团队只有在10人以内，我们使用一个跨职能的Scrum团队，可以很容易地按照scrum和敏捷的方式开发产品。 但是，如果产品团队规模较大，比如是几十人，甚至几百人的开发团队的时候，我们就需要考虑团队的结构和组织方式。
在一个大的开发组织中，Scrum会把大的开发团队划分成多个5-9人的小团队，那么我们应该按照什么方式来划分呢？
在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式，我们称之为组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。
组件团队看起来像这个样子：
按照Scrum和敏捷的交付模式，组件团队有如下一些限制：
第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。
第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。
第三：由于职责单一，限制了学习，使得专业更加单一化
第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付
按照Scrum和敏捷的交付模式，以用户为中心，按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。
特性团队的特点：
特性团队看起来像这个样子：
特性团队的好处：
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a , I want to , so that .
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
关于用户故事，Ron Jeffries用3个C来描述它：
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
无论是团队研发一款产品或者开发某一个项目，我们都需要回答“我们大概什么时间能够完成？”， 或者到某一个时间点，我们能够做到什么程度， 因此和传统的开发模式一样，我们在工作开始之前需要对我们需要做的事情进行工作量的估算。
相对与传统的工作量估算方式，敏捷估算有如下几个特点：
在Scrum的开发过程中，团队共担责任，集体承诺每个Sprint的工作，因此对于工作量的估算敏捷团队采用集体估算的方式。集体估算，通常采用估算扑克作为工具，团队通过玩估算游戏进行集体估算。使用估算扑克来做工作量估算是最有效，也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字，可供4个人使用。
估算扑克的使用方法：
关注Scrum中文网微信公众号可以获得微信版估算扑克。
一瓶矿泉水，让一个3岁的小妹妹把它喝完所花的时间和一个成年人把它喝完所花的时间肯定不一样，因此同一项工作，不同能力的人完成它花费的时间显然是不一样的。如果我们要估算从家到公司的绝对距离时多少公里，您可能不一定知道，但是如果您时做地铁上班，从家里到公司有多少站，你一定很容易知道，当我们知道有多少站之后，我们就可以大概清楚路上需要花多长时间了。敏捷估算时，我们不会估算绝对时间和周期，我们估算大小，和相对值，也就是倍数。敏捷估算时，我们使用故事点作为计量单位，它是一个倍数，我们会先找一个我们认为最小的一个功能的大小作为参考基准，定义为1个故事点，把其它的故事和它做比较，如果是2倍大小，就是2个故事点，如果是5倍大小，就是5个故事点。
团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数，通过团队速率可以知道团队做的有多快。新开始的项目或产品开发，或者是新团队，没有初始速度，我们可以做1-2个Sprint测算一个速度，作为初始速度。在Sprint执行过程中，我们要记录每个Sprint的速度，为以后的计划做参考。
我们估算了产品Backlog的故事点总数，然后又知道了每个Sprint团队的平均速度，那么我们就可以推算我们大概需要多少个Sprint可以做完，这样我们就得到了周期。
Scrum是一种迭代和增量式的产品开发方法，Scrum通过Sprint来实现迭代。一个Sprint是指一个1周－4周的迭代，它是一个时间盒。Sprint的长度一旦确定，保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品增量。Sprint 在整个开发过程中的周期一致。新的 Sprint 在上一 个 Sprint 完成之后立即开始。 Sprint 包含并由 Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。
Scrum采用迭代增量的方式，是因为需求是涌现的，我们对产品和需求的理解是渐进式的，Sprint长度越长，我们需要预测的越多，复杂度会提升、风险也会增加，所以Sprint的长度最多不超过4周。越来越多的团队使用2周的Sprint，很多市场变化快、竞争激烈的领域，比如互联网和移动互联网产品开发团队也会使用1周的迭代。
在Sprint进行过程中，如下内容不能发生变化：
在Sprint执行的过程中，团队要避免一个萝卜一个坑的工作方式，团队要协作，并且要集中优势兵力各个击破。
团队按照蜂拥式（Swarming）的工作方式，团队先集中工作在少数几个需求上面，协作完成它们，然后在开始下一批需求。按照这样的方式一方面可以加强团队协作，另外也有利于及早完成一些需求，让这些需求及早验收。
Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权 力,但他做这样的决定也可能是受到利益干系人、团队或是 Scrum Master 的影响。
如果某个 Sprint 的目标过时了,那么就需要取消该 Sprint。比如公司的发展方向, 或是市场、技术等情况发生了变化,这些变化都可能导致取消 Sprint。总的来说,如果某 个 Sprint 对于其所在环境来说失去了价值和意义,那么它就应该被取消。然而,因为 Sprint 周期都较短,所以很少发生取消 Sprint 的情况。
当某个 Sprint 被取消时,任何做完和“完成”的产品待办事项列表条目都需要评审。假如有些条目已经潜在可交付,那产品负责人就会采纳它。所有未完成的条目就都要 放回到产品待办事项列表中,并重新估算。花在它们身上的工作会迅速贬值,所以需要频 繁地重估。
取消 Sprint 会消耗资源,因为每个人都需要在新召开的 Sprint 计划会议中重新开始 另一个 Sprint。Sprint 终止通常会对团队造成重创,因此这种情况也非常少见。
在介绍如何开每日站会前，让我们先了解一下召开每天的站会的目的和意义是什么？敏捷宣言强调个体交互重于过程和工具，敏捷原则阐述了面对面的沟通和自组织的团队这些敏捷的核心思想。Scrum的团队是一个自组织的团队，团队每天进行每日站会是团队面对面沟通和团队自组织的体现。Scrum的理论基础是通过保持过程透明性让参与过程的所有人了解真实状况，然后进行检查和调整，每日站会是Scrum过程进行每天的检查和调整的环节。
Scrum定义了开展每日站会的一些基本的规则。每日站会必须每天在同一时间、同一地点召开，最好的方式是在团队的可视化的任务板前面召开。 任务板上可以看到当前Sprint的燃尽图（Burn Down Chart）和Sprint中每个任务的状态。
在每日站会开始之前，团队需要在任务板上更新任务的状态。这样的好处是在开会的时候，每个人都可以看到当前的进展情况。
每日站会是Scrum团队每天的第一件事情，这样可以让每个人在每天一开始就清楚的了解他一天的安排。对于跨国界的团队，存在时间差的情况，可以根据实际情况做调整。
会议时间最多不超过15分钟。所有的团队成员自觉按时到场，因为会议很短，按时召开按时结束是很重要的。团队需要建立他们的工作协议来确保团队成员按时出席，并且遵守站会纪律，比如团队可以商量对于迟到的人员要有一些让他们改进的措施，比如适当的给一些罚金，多少由团队共同决定，这些钱如何支配也由团队共同决定， 或者做俯卧撑、挂一个迟到的牌子等等。
每日站会一定要站着开，每个人要精神集中，不能有懒散的表现。
每个人回答三个问题：
我昨天完成了什么任务？
我今天打算完成什么任务？
我遇到了哪些障碍或困难？
同一时间只能有一个人发言，会上只说和这三个问题相关的话题，任何跑题的讨论，需要被ScrumMaster制止。一些的确需要讨论的问题，可以先记录下来，会后作为专题来讨论。
每日站会和传统的项目会议有如下几点不同：
Scrum的最基本原则是“Inspect and Adapt”(检视然后适应)，如果什么事情做得很好，问问自己为什么，然后寻找提升的办法。
如果每日站会没有效果，检查一下这些规则：你是不是每天在认真开每日站会？如果不是为什么？如果你改变了Scrum的一些基本的规则，你可能会面临一些风险，因为这些规则都是经过锤炼和项目考验的一些通用规则。所以第一步，你可以先按照书本上的方式来做。
如果这还不够，参考一下其他人的实践经验，比如：Martin Fowler’s 《Patterns of Daily Stand-up Meetings》
一个好的每日站会有如下几个特点：
一个自组织的团队有一个非常明显的每天的节奏：Daily Scrum之前非常安静，每日站会之后会有一段活跃的讨论，到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论，当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能够感受到这个节奏，则说明团队是很健康的，每日站会起到了很好的效果。
当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完 成”意味着什么。虽然这在不同的 Scrum 团队之间会有巨大的差别,但是团队成员必须对 完成工作意味着什么有相同的理解,这样才能保证透明性。这就是 Scrum 团队的“完成” 定义,用来评估产品增量在什么时候完成。
这个定义也同时被用来指导开发团队了解在 Sprint 计划会议的时候他们能选择多少 产品代办事项列表条目。每个 Sprint 的目标都是交付遵循 Scrum 团队当前的“完成”定 义的潜在可交付功能增量。
开发团队在每个 Sprint 交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。
随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。
需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。
一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议，控制时间盒以及处理团队成员提出的障碍的话，你可以将这个角色当作成兼职来对待。在这种情况下，团队仍然有可能达到预期的目标，而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候，你就成为了一位出色的ScrumMaster。
一位出色的ScrumMaster一次能够负责一个团队。
我们推荐每个7人左右的团队都有一位专职的ScrumMaster，尤其是刚开始实施Scrum的时候。
如果你还没有发现你能够做的事情的话，尝试聆听Product Owner，团队还有团队以外的公司成员的想法。下面我列出了一些ScrumMaster常忽略的东西。
恐惧是你的朋友, 一旦你开始意识到你能够做些事情来改变现状，你可能会感到恐惧而退缩。然而，这正是你走上正轨的标志。
原文地址：http://www.scrumalliance.org/articles/194-an-example-scrummasters-checklist
