Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum 中，使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具有较高价值的需求。在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级的需求进行开发。挑选的需求在 Sprint 计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为 Sprint backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。 Scrum 起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 的基本流程如图 6-7 所示。

1．Scrum 的五个活动
Scrum 主要包括：产品待办事项列表梳理、Sprint 计划会议、每日 Scrum 会议、Sprint 评审会议、Sprint 回顾会议等五个活动。
（1）产品待办事项列表梳理
产品待办事项通常会很大，也很宽泛，而且想法会变来变去、优先级也会变化，所以产品待办事项列表梳理是一个始终贯穿整个 Scrum 项目的活动。该活动包含但不限于以下的内容：保持产品待办事项列表有序、把看起来不再重要的事项移除或者降级、增加或提升涌现出来的或变得更重要的事项、将事项分解成更小的事项、将事项归并为更大的事项、对事项进行估算。
产品待办事项列表梳理的一个最大好处是为即将到来的几个 Sprint 做准备。为此，梳理时会特别关注那些即将被实现的事项。需要考虑不少因素，这包括但不限于以下的内容：
理想情况下，下一个 Sprint 的备选事项都应该提升“商业价值”。开发团队需要能够在一个 Sprint 内完成每一个事项。每个人都需要清楚预期产出是什么。
产品开发决定了，有可能需要其他的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动，而不单单是产品负责人。
（2）Sprint 计划会议
每个 Sprint 都以 Sprint 计划会议作为开始，这是一个固定时长的会议，在这个会议中，Scrum 团队共同选择和理解在即将到来的 Sprint 中要完成的工作。
整个团队都要参加 Sprint 计划会议。针对排好序的产品待办事项列表（Product Backlog），产品负责人和开发团队成员讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。所有的 Scrum 会议都是限定时长的。Sprint 计划会议推荐时长是 Sprint 中的每周对应两小时或者更少（例如，一个 Sprint 包含 2 个星期，则 Sprint 计划会议时长应为 4 个小时或者更少）。因为会议是限制时长的,Sprint 计划会议的成功十分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。
在 Scrum 中，Sprint 计划会议有两部分：
决定在 Sprint 中需要完成哪些工作
决定这些工作如何完成
第一部分：需要完成哪些工作?
在会议的第一部分，产品负责人向开发团队介绍排好序的产品待办事项，整个Scrum团队共同理解这些工作。
Sprint 中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少，开发团队需要考虑当前产品增量的状态，团队过去的工作情况，团队当前的生产能力，以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其他人，都不能给开发团队强加更多的工作量。
通常 Sprint 都有个目标，称作 Sprint 目标。这将十分有效地帮助大家更加专注于需要完成的工作的本质，而不必花太多精力去关注那些对于我们需要完成的工作并不重要的小细节。
第二部分：如何完成工作？
在会议的第二部分里，开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划，从而有信心可以在 Sprint 中完成所有工作。前几天的工作会被分解成小的单元，每个工作单元不超过一天。之后要完成的工作可以稍大些，以后再对它们进行分解。
决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。在计划会议的第二部分，产品负责人可以继续留下来回答问题，以及澄清一些误解。
不管怎样，团队应该很容易找到产品负责人。
Sprint 计划会议的产出。Sprint计划会议最终需要 Scrum 团队对 Sprint 需要完成工作的数量和复杂度达成共识，并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。总而言之：在 Sprint 计划会议中，开发团队和产品负责人一起考虑并讨论产品待办事项，确保他们对这些事项的理解，选择一些他们预测能完成的事项，创建足够详细的计划来确保他们能够完成这些事项。
最终产生的待办事项列表就是“Sprint 待办事项列表（Sprint Backlog）”。
（3）每日 Scrum 会议
开发团队是自组织的。开发团队通过每日 Scrum 会议来确认他们仍然可以实现 Sprint 的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息：
从上一个每日 Scrum 到现在，我完成了什么；从现在到下一个每日 Scrum，我计划完成什么；有什么阻碍了我的进展。
每日 Scrum 中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。通常，许多团队会在每日 Scrum 之后马上开会处理他们遇到的任何问题。
每日 Scrum 既不是向管理层汇报，也不是向产品负责人或者 ScrumMaster 汇报。它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解。只有 Scrum 团队的成员，包括 ScrumMaster 和产品负责人，可以在会议中发言。其他感兴趣的人可以来旁听。在必要时，开发团队会基于会议中的发现重新组织他们的工作来完成 Sprint 的目标。
每日 Scrum 是 Scrum 的一个关键组成部分，它可以带来透明性,信任和更好的绩效。它能帮助快速发现问题，并促进团队的自组织和自立。所有 Scrum 会议都是限定时长的。每日 Scrum 通常不超过 15 分钟。
（4）Sprint 评审会议
Sprint 结束时，Scrum 团队和相关人员一起评审 Sprint 的产出。Sprint 评审会议的推荐时长是 Sprint 中的每一周对应一个小时（例如，一个 Sprint 包含 2 个星期，则 Sprint 评审会议时长为 2 个小时）。
讨论围绕着 Sprint 中完成的产品增量。由于 Sprint 的产出会涉及一些人的“利益”，因此一个明智的做法是邀请他们参加这个会议，这会很有帮助。这个会议是个非正式的会议,帮助大家了解我们目前进展到哪里，并一起讨论我们下一步如何推进。每个人都可以在 Sprint 评审会议上发表意见。当然，产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表 Product Backlog。
团队会找到他们自己的方式来开 Sprint 评审会议。通常会演示产品增量,整个小组也会经常讨论他们在 Sprint 中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表的状态、可能的完成日期以及在这些日期前能完成什么。
Sprint 评审会议向每个人展示了当前产品增量的概况。因此，通常都会在 Sprint 评审会议中调整产品待办事项列表。
（5）Sprint 回顾会议
在每个 Sprint 结束后,Scrum 团队会聚在一起开 Sprint 回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。Sprint 回顾会议的推荐时长是 Sprint 中的每一周对应一个小时（例如，一个 Sprint 包含 2 个星期，则 Sprint 回顾会议时长为 2 个小时）。
Scrum 团队总是在 Scrum 的框架内，改进他们自己的流程。
2．Scrum 的 5 大价值观
Scrum 的 5 大价值观为：
承诺—愿意对目标做出承诺。
专注—把你的心思和能力都用到你承诺的工作上去。
开放—Scrum 把项目中的一切开放给每个人看。
尊重—每个人都有他独特的背景和经验。
勇气—有勇气做出承诺，履行承诺，接受别人的尊重。